PrefectHQ/prefect - CodSpeed

prefect

Blog Docs Changelog

Performance History

Latest Results

Stop the suspension observer without waiting for it in the async engine The async engine waited up to 2 s for the suspension observer's thread to shut down, and held back any cancellation that arrived during that wait. An anyio cancel scope sends the cancellation again on every loop iteration, so the wait ran at full CPU. On Python 3.11, `asyncio.wait_for` can also lose a cancellation that arrives as the wait completes. The async engine now stops the observer and returns without waiting, as it already does for its heartbeat thread. The sync engine now waits for the observer's initial state check inside the `try`, so a signal such as SIGTERM that interrupts the wait still stops the observer thread. A cancellation of the observer that `stop` did not request is now logged at debug level instead of being discarded. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fatih-acar:fix/async-suspension-observer

10 hours ago

Avoid UPDATE ... RETURNING for SQLite < 3.35 support (OSS-8373)

devin/oss-8373-readiness-after-redis-recovery

11 hours ago

Stop the async flow engine from blocking its event loop on the suspension observer The suspension observer of a deployment flow run runs on its own thread and event loop, but the async engine waited for it on the calling thread: it blocked until the observer was ready when the run started, and joined the observer thread (up to 2 s, with the observer polling for stop every 0.2 s) when the run ended. When several flow runs share one event loop, each start and end stalled all of them. The async engine now waits for the observer to be ready and to shut down through thread-safe events, without blocking its loop. The observer stays on its own thread so it keeps receiving suspension events while flow code blocks the flow's thread. Stopping the observer now cancels it, so it stops at once, also during its initial state check, instead of within 0.2 s. A cancellation that reaches the async engine while it waits for the observer to shut down is raised after the wait, so it does not replace an exception such as `Pause`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

fatih-acar:fix/async-suspension-observer

11 hours ago

Replace stuck readiness tasks when a poll would mark something ready (OSS-8373) A readiness task left pending with its key known (e.g. a failed claim during a Redis disruption) deduplicated every later poll until docket's redelivery timeout, leaving work queues and deployments NOT_READY for ~5 minutes. Closes #23643 Co-authored-by: Alexander Streed <desertaxle@users.noreply.github.com>

devin/oss-8373-readiness-after-redis-recovery

11 hours ago

Link to the docs at www.prefect.io/docs (#23642)

main

12 hours ago

Link to the docs at www.prefect.io/docs

maxime/link-docs-at-www-prefect-io

13 hours ago

docs: Set canonical URLs to www.prefect.io (#23641)

main

14 hours ago

Normalize nonexistent cron starts and end exhausted gap streams (OSS-8371) Co-authored-by: Alexander Streed <alex.s@prefect.io>

devin/oss-8371-cron-gap-recovery

16 hours ago

Latest Branches

0%

Stop the async flow engine from blocking its event loop on the suspension observer#23274

10 hours ago

82ca0b7

fatih-acar:fix/async-suspension-observer

0%

Replace stuck readiness tasks when a poll would mark something ready#23644

11 hours ago

91c8fd8

devin/oss-8373-readiness-after-redis-recovery

0%

Link to the docs at www.prefect.io/docs#23642

13 hours ago

33637dc

maxime/link-docs-at-www-prefect-io

© 2026 CodSpeed Technology

Home Terms Privacy Docs