Found while scoping orchestration #175.
selector/testdb.py creates a per-test database and drops it in a finally:. The drop is not reliably happening: 23 selector_test_<hex> databases were on the local Postgres alongside selector, counted 2026-08-26 with
psql -d postgres -tAc "SELECT count(*) FROM pg_database WHERE datname LIKE 'selector\_test\_%'"
Why it matters beyond tidiness: the same module is the intended builder for selector_staging, and "the throwaway database goes away" is an assumption that work would otherwise inherit. Better to know the drop path is unreliable before something depends on it.
Likely causes worth checking in order:
_drop() raising because a session is still attached - the with psycopg.connect(dsn, ...) block inside throwaway_db() holds a connection to the database being dropped - and the exception being swallowed or aborting the run.- Interrupted or crashed test runs never reaching the
finally: at all: pytest killed, a SIGKILL, or a hung NOTIFY listener.
Two things to land:
• Make the drop robust: DROP DATABASE ... WITH (FORCE) (Postgres 13+, and this box is on 16), or terminate backends on the target first.
• A cleanup path for the ones already there, and something that makes the leak visible rather than silent - the count is only discoverable by going and looking.
Originally filed as Educational-Travel-Adventures/orchestration#178.
Note: Core implementation landed in orchestration#324 and carried into Tracewake at selector/tests/test_testdb.py.
Found while scoping orchestration #175.
selector/testdb.pycreates a per-test database and drops it in afinally:. The drop is not reliably happening: 23selector_test_<hex>databases were on the local Postgres alongsideselector, counted 2026-08-26 withWhy it matters beyond tidiness: the same module is the intended builder for
selector_staging, and "the throwaway database goes away" is an assumption that work would otherwise inherit. Better to know the drop path is unreliable before something depends on it.Likely causes worth checking in order:
_drop()raising because a session is still attached - thewith psycopg.connect(dsn, ...)block insidethrowaway_db()holds a connection to the database being dropped - and the exception being swallowed or aborting the run.finally:at all:pytestkilled, aSIGKILL, or a hung NOTIFY listener.Two things to land:
• Make the drop robust:
DROP DATABASE ... WITH (FORCE)(Postgres 13+, and this box is on 16), or terminate backends on the target first.• A cleanup path for the ones already there, and something that makes the leak visible rather than silent - the count is only discoverable by going and looking.
Originally filed as Educational-Travel-Adventures/orchestration#178.
Note: Core implementation landed in orchestration#324 and carried into Tracewake at
selector/tests/test_testdb.py.