Latest Results
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 Latest Branches
0%
chuqCTC:fix/23129-conditional-mark-deployments-ready 0%
devin1/oss-8223-flow-ends-completed-when-it-returns-a-list-of-map-results 0%
WAHIB-EL-KHADIRI:fix/db-vacuum-connection-contention © 2026 CodSpeed Technology