Prefect 3.7.4 - Lifecycle Events and Cleanup Delivery
Prefect 3.7.4 was published on June 5, 2026, with a practical set of changes for teams running Prefect in production. The main user visible change is broader lifecycle event emission for domain objects, while the operator side gets more cleanup delivery work around Redis, worker channels, leases, retries, and recovery.
The full release notes and downloads are on the GitHub release page.
Lifecycle events cover more Prefect objects
The largest change in Prefect 3.7.4 is that Prefect now emits lifecycle events for all domain objects covered by the release notes. That includes variables, flows, block documents, block types, concurrency limits, artifact collections, and automations.
The event names are simple: created, updated, and deleted. That matters for teams that use events as the audit trail around orchestration state. A variable update, a block document change, or an automation removal can now be seen as part of the same event model instead of being treated as a quiet metadata edit.
This is especially useful for operators who have to answer dull but important questions. What changed before this flow started failing. Who updated an automation. Did a concurrency limit move before a backlog grew. The release notes do not describe a new user interface for this, but the event coverage itself is the important backend behavior.
The change comes from PR 22226.
Cleanup delivery gets Redis and worker channel work
Several changes in 3.7.4 focus on cleanup message delivery. Prefect adds a Redis backed cleanup queue backend with optimistic transactions and cross process wakeups. In plain terms, this is about making cleanup coordination work across more than one process without pretending that one process owns the whole world.
The release also adds a cleanup reconciler for worker channel delivery. The notes call out lease expiry, retry, and dead-letter policies. Those are operator words, and they are good ones. Cleanup messages need a path for normal delivery, a path for retry, and a path for messages that cannot be handled after repeated attempts.
There is also a cleanup delivery dispatcher that routes reserved cleanup messages to workers over WebSocket. Together, these changes point at a more explicit delivery pipeline for cleanup work. It is mostly plumbing, but it is the kind of plumbing that decides whether background services recover cleanly or leave someone reading logs after dinner.
Related changes are in PR 22109, PR 22205, and PR 22206.
Deployment and CLI fixes reduce rough edges
Prefect 3.7.4 includes a few fixes around deployment setup and command execution. The release fixes deploy init field parsing, which should reduce bad output from setup paths that depend on those parsed fields.
It also fixes the prompt that saves new deployments into an existing prefect.yaml. That is a small workflow detail, but it is the sort of thing that matters when teams standardize deployment configuration in a repo and expect the tool to edit the existing file cleanly.
Another fix filters stdlib paths from PYTHONPATH to prevent subprocess CLI breakage. This is a boring Python environment problem until it breaks a CLI command from a subprocess. Then it becomes the only thing anyone cares about for the next hour.
Git clone errors also get a small improvement. When no known hint matches, Prefect now surfaces sanitized git clone stderr in error messages. That should make repository access, auth, and clone failures less opaque without dumping raw unsafe output.
Automation and docs updates
The read_automations client methods now accept configurable filter params: automations, sort, limit, and offset. This is a useful change for clients that need to page through automation data or request a specific ordering instead of fetching a broad set and sorting locally.
The documentation updates are also concrete. Prefect Cloud API docs now mention the max request size limit. The automation docs mention the flow_run_log_summary template variable. The retries guide now uses canonical PREFECT_TASKS_* environment variables.
The docs also clarify runtime auto install gating conditions and document a deployment schedule clear command. None of that changes runtime behavior by itself, but it reduces guesswork around commands and config names.
Upgrade notes
The release notes do not list breaking changes, deprecations, or migration steps for Prefect 3.7.4. It is also not marked as a prerelease.
Operators using Redis backed services should still read the cleanup delivery entries before rollout. The notable behavior changes are around cleanup queues, worker channel delivery, retry handling, and recovery after Redis disruption. That last fix is explicit in the notes: perpetual services now recover after Redis disruption.
Where to get it
- Release page: Prefect 3.7.4
- Repository: PrefectHQ/prefect
- Tag:
3.7.4