Thanks for the detail — that error and the “works after server restart” symptom line up with a known bug in Prefect 3.4.x around automations. Short answer to your question: the PR you linked is not the one you need. - PR you referenced: #18302 drops a task_run -> task_run_state foreign key. It does not touch automations or

automation_bucket

. What you’re hitting matches this issue and its fix: - Issue with the same FK error and “automations stop firing until restart”: prefect#19332 - Fix: Fix automation deletion deadlock by enforcing consistent lock ordering What’s going on - During (re)deploys, automations/triggers can be deleted/recreated while the event processor is still handling messages. In 3.4.x there’s a race where event processing tries to insert/update

automation_bucket

rows for an automation_id that has just been deleted, causing the FK violation:

asyncpg.exceptions.ForeignKeyViolationError: insert or update on table "automation_bucket" violates foreign key constraint "fk_automation_bucket__automation_id__automation"

- With the in-memory messaging backend, a failed message can keep retrying and clog the consumer; restarting the API server clears that memory queue, which is why things “recover” after a restart. How to resolve - Recommended: upgrade your API server to the latest 3.6.x (currently 3.6.2), which includes multiple automations fixes, including the one linked above. - If you’re using our image:

docker pull prefecthq/prefect:3.6.2-python3.13

Then restart your server with that tag. Migrations will run on startup. - If you must stay on 3.4.x temporarily: - Minimize automation churn during deploys (avoid deleting/recreating automations while events are flowing). - As a mitigation during rollouts, pause/disable affected automations (or stop the API server briefly) before redeploying, then resume — this avoids the race that produces FK errors. - If you get into the bad state, a server restart will clear the in-memory dead-lettered message and unblock processing (as you’ve seen). If you’d like, I can help validate your exact deploy flow to reduce the likelihood of the race on 3.4.x, but the durable fix is to upgrade to 3.6.x where this was addressed. Links for reference - Not relevant to this issue: PR #18302 - Matching report: Issue #19332 - Fix: PR #19369 - Latest release: 3.6.2 Does this line up with your deploy pattern (redeploys that replace automations/triggers)? If so, I’d recommend moving to 3.6.2 next; I can also suggest a safer redeploy sequence for your environment if you share how you’re invoking

deploy()

.

Short answer: not required for this fix, but recommended. - The FK violation and stuck automations are entirely server-side; upgrading the API server to a version that includes the fix (PR #19369, in 3.6.x) resolves it. Upgrading workers is not necessary to address this specific issue. - That said, we do recommend keeping server and workers on the same minor version when practical to pick up client/worker bug fixes (polling, concurrency, retries) and avoid subtle API drift. The latest is 3.6.2. Practical guidance - Order: upgrade server first (let migrations run), verify automations fire, then upgrade workers during your next window. - If your flow run images pin Prefect (e.g., custom Docker images), they can continue to run on 3.4.x against a 3.6.x server, but consider rebuilding them to 3.6.x for parity when convenient. If you share your worker type (docker/k8s/process) and how your job images are built, I can suggest the cleanest upgrade path.