Prefect 3.8.1 was published on July 30, 2026. Its most important operator change keeps worker startup alive when the Prefect API cannot be reached, changing a temporary control plane outage from an immediate startup failure into a condition the worker can survive. The release also corrects infrastructure retry, process lifecycle, deployment parameter, and API filter behavior.
The full release notes and downloads are on the GitHub release page.
Worker startup survives API loss ¶
Pull request 22640 keeps worker startup alive when the Prefect API is unreachable. This changes a useful failure boundary. A temporary API outage no longer has to terminate the startup path and leave an operator with a worker process to restart after the control plane recovers.
That survival does not make a disconnected worker healthy. Process status and successful API communication remain separate signals. Alerting should still distinguish a running worker from one that can reach Prefect and accept work. The fix removes an unnecessary process exit; it does not remove the operational effect of API loss.
Pull request 22622 addresses the other side of infrastructure failure. Prefect now relinquishes evicted flow runs to infrastructure retry. Eviction is not an application exception inside flow code, so returning the run to infrastructure retry gives the orchestration layer another chance to place it instead of treating the lost execution environment as ordinary flow logic.
The notes do not describe a new setting, retry count, or migration step. Existing retry policy still deserves verification in a staging work pool, especially where external systems make repeated execution expensive.
Output errors no longer decide subprocess lifetime ¶
Pull request 22573 preserves subprocesses after output stream errors. An error while reading or forwarding process output no longer decides whether the launched child process stays alive. That separation matters for flows that invoke long running tools whose useful work can continue even when log capture has a problem.
There is an operator tradeoff. Missing output can now coexist with a live subprocess, so log silence cannot be treated as proof that the process exited. Process monitoring and output stream monitoring need distinct checks. This is still safer than allowing a secondary logging path to control the lifetime of the work itself.
Deployment inputs and API filters get stricter ¶
Pull request 22568 fixes saved block parameters in deployments. Deployment parameters are part of the execution contract, and block backed values need to survive the save and load path unchanged. Teams that saw deployment inputs disappear or arrive incorrectly should retest that path after upgrading rather than adding another workaround around parameter storage.
Pull request 22659 rejects unknown fields in FlowRunFilter and its nested criteria. Custom API clients that construct filter payloads by hand may now receive validation failures for misspelled or obsolete fields. That is stricter behavior, but it prevents an invalid predicate from being silently ignored and returning a wider set of flow runs than the caller intended.
Before rollout, run representative saved deployments and flow run queries against a test API. The release notes identify no broad migration, but these two fixes sit on interfaces where previously tolerated bad state can become visible during an upgrade.