PrefectHQ
prefect
Blog
Docs
Changelog
Blog
Docs
Changelog
Overview
Branches
Benchmarks
Runs
Performance History
Latest Results
Fix two tests that do not check what their names say (#23142) Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: Alexander Streed <alex.s@prefect.io>
main
4 hours ago
Bump soupsieve from 2.8.4 to 2.9 (#23147) Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Alex Streed <desertaxle@users.noreply.github.com>
main
4 hours ago
fix date clearing on cancel (#23148)
main
6 hours ago
Make no-op comparisons in tests actually assert (#23141) Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
main
1 day ago
Add Osano consent manager to Prefect docs (#23133)
main
1 day 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
1 day 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
1 day 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
1 day ago
Latest Branches
CodSpeed Performance Gauge
0%
Only write deployments that a poll actually changes
#23130
1 day ago
c6da1b6
chuqCTC:fix/23129-conditional-mark-deployments-ready
CodSpeed Performance Gauge
0%
Aggregate nested iterables of states when determining final state
#23139
1 day ago
f559a7b
devin1/oss-8223-flow-ends-completed-when-it-returns-a-list-of-map-results
CodSpeed Performance Gauge
0%
Give each db_vacuum kind its own connection pool
#23136
2 days ago
be3eb3e
WAHIB-EL-KHADIRI:fix/db-vacuum-connection-contention
© 2026 CodSpeed Technology
Home
Terms
Privacy
Docs