fix(conftest): tuple-based prod DSN identity check #26
Reference in New Issue
Block a user
Delete Branch "fix/conftest-test-db-isolation"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why this follow-up
PR #25 was merged, but a Kay review caught a hole: the prod-safety guard used a host-or-port check. Port 5432 in the compose network is also the in-container test DB port (db-test:5432). A worker running pytest inside the orchestrator container pointing at the in-container test DB would have been wrongly blocked by the old port check.
This replaces the host/port check with a full (host, port, user, dbname) tuple check. The four canonical prod tuples are explicitly listed; any other combination is treated as not-prod.
What changes
tests/conftest.py: replace_PROD_HOSTS/_PROD_PORTSwith_PROD_DSNS(set of tuples)._prod_safety_guard()now builds the full DSN tuple from DB_CONFIG and checks membership.tests/test_conftest_safety.py: 13 tests (was 8). New tests cover:db-test:5432/damascus_test/damascus_test) is treated as not-proddamascus→wrong_user) is treated as not-prod_PROD_DSNScontains exactly the four canonical prod tuples_PROD_DSNSdoes NOT contain any test tupleVerification
pytest tests/test_conftest_safety.py -v→ 13 passedpytest tests/contract/ tests/unit/ -v→ 65 passed (no regressions)Deployment order (same as PR #25)
docker compose up -d --force-recreate --no-deps orchestrator orchestrator-schedulerAfter #4, any worker pytest run hits
db-test(port 5433 host / 5432 container) and prod work_items survives — both via the host-loopback port and the in-container compose network.