PrefectHQ/prefect

PrefectHQ

prefect

Blog Docs Changelog

Performance History

Latest Results

Make no-op comparisons in tests actually assert (#23141) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

main

11 hours ago

Add Osano consent manager to Prefect docs (#23133)

main

12 hours ago

Only write deployments that a poll actually changes Every worker poll updated every deployment on the work pool's queues, even when nothing had changed. A queue with N deployments meant N row updates per poll. A poll now writes a deployment only if it is not READY, or if its last_polled is older than half of deployment_last_polled_timeout_seconds. Half the timeout keeps last_polled inside the timeout for any poll interval. The CTE still locks every candidate row. A filter there would skip rows, and skipped rows are not locked. A stale NOT_READY from the Foreman could then overwrite a fresh poll. So the rows to write are chosen after the lock. The update writes them in batches, under get_max_query_parameters(). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

chuqCTC:fix/23129-conditional-mark-deployments-ready

15 hours ago

Only write deployments that a poll actually changes `mark_deployments_ready` updated every deployment on the polled work pool's queues regardless of their current state, so a queue with N deployments produced N row updates per execution even with nothing scheduled or running. Write only the rows that need it: not `READY`, or a `last_polled` older than half of `deployment_last_polled_timeout_seconds`. Half the timeout keeps the worst-case age of `last_polled` at or below the timeout for every poll interval, so nothing that stays `READY` today starts flapping. The `locked` CTE keeps taking `FOR UPDATE` on every candidate row. Filtering there instead would skip the lock and let a concurrent stale `NOT_READY` transition win over a fresh poll, which is the hazard the `SKIP LOCKED` comment above it describes. The staleness decision is therefore made from the locked rows, with the clock read after the locking SELECT returns so that a row ageing past the refresh point during the lock wait is still refreshed. The UPDATE targets the ids just read, batched under `get_max_query_parameters()`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

chuqCTC:fix/23129-conditional-mark-deployments-ready

15 hours ago

Aggregate nested iterables of states when determining final state Closes #23137 Co-authored-by: Alexander Streed <desertaxle@users.noreply.github.com>

devin1/oss-8223-flow-ends-completed-when-it-returns-a-list-of-map-results

18 hours ago

Fix engine-cache collision the previous commit missed Devin's review on this PR caught it: AsyncPostgresConfiguration.engine() has its own ENGINES cache keyed only on (loop, connection_url, echo, timeout). Every per-kind maintenance config built by the previous commit shares identical values for all four, so they all resolved to the same cached engine (and pool) regardless of the distinct config objects — the actual bug was never fixed, only hidden behind three config wrappers that all pointed at one engine underneath. Fix at the root: sqlalchemy_pool_size, sqlalchemy_max_overflow, and connection_app_name are real per-engine settings (baked into the pool and connection identity at construction) that were simply missing from the cache key — two configs differing only in one of these already silently collapsed onto whichever was built first, for any caller, not just db_vacuum. Add them to the cache key. db_vacuum then sets a distinct connection_app_name per kind ("prefect-db-vacuum-<kind>"), which is what actually forces flow_runs/events/orphans onto separate engines now that the cache key accounts for it. As a side benefit it shows up in pg_stat_activity, so an operator can tell the three vacuum connections apart. New regression test awaits .engine() itself (not just the config objects) and asserts the three are distinct engines, per Devin's recommendation, plus that one kind's repeated calls still reuse its own engine. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

WAHIB-EL-KHADIRI:fix/db-vacuum-connection-contention

22 hours ago

Give each db_vacuum kind its own connection pool flow_runs/events/orphans vacuum shared one cached, single-connection AsyncPostgresConfiguration keyed only by connection_url. Docket is Redis-backed and each kind's tasks are enqueued independently, so nothing prevents two kinds' tasks from running concurrently and contending for that one connection. Key the cache by (connection_url, kind) instead so each kind gets its own dedicated pool; batches within one kind still share one connection sequentially, which remains correct since each kind's own loop only enqueues its next task after the previous one completes. Fixes the connection-contention half of #22839. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

WAHIB-EL-KHADIRI:fix/db-vacuum-connection-contention

1 day ago

Take the lock before deciding a deployment is fresh Filtering inside the `locked` CTE skipped the `FOR UPDATE`, so a concurrent uncommitted `NOT_READY` from the Foreman could win over a fresh poll — the hazard the `SKIP LOCKED` comment above it describes. Keep the CTE state-independent and choose the write set from the locked rows instead, reading the clock after the locking SELECT so that a row ageing past the refresh point during the lock wait is still refreshed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

chuqCTC:fix/23129-conditional-mark-deployments-ready

1 day ago

Latest Branches

Only write deployments that a poll actually changes#23130

15 hours ago

c6da1b6

chuqCTC:fix/23129-conditional-mark-deployments-ready

Aggregate nested iterables of states when determining final state#23139

18 hours ago

f559a7b

devin1/oss-8223-flow-ends-completed-when-it-returns-a-list-of-map-results

Give each db_vacuum kind its own connection pool#23136

22 hours ago

be3eb3e

WAHIB-EL-KHADIRI:fix/db-vacuum-connection-contention

Home Terms Privacy Docs