ARR-2.0-0918/.project-docs/50-evidence/topics/2026-09-16-arr-postgres-download-acceptance.md

Isolated real PostgreSQL acceptance for ARR downloads

2026-09-16. User asked to continue. Source task was independently working on company/name/order semantics, so this task closed the documented real-SQL validation gap without duplicating source rules. Accepted UI and runtime stayed unchanged.

Environment and scope

Host PostgreSQL15.19/Homebrew and existing psycopg were used. tests/local_postgres.py creates an owner-only temporary cluster/socket directory, disables TCP, clears libpq environment defaults in the test process, explicitly connects to the new socket, and verifies SHOW data_directory/listen_addresses on every connection. It cannot accept a user DSN, host, existing cluster or production configuration. The isolated database is named booking_test solely to satisfy existing guards.

Each case starts with an empty database and applies the unchanged current008–018 migrations. Bootstrap/destructive reset occurs only after the connection is verified to belong to this newly owned cluster. No production backup, schema, migration ledger, credentials or data was read/changed. Schema/application SQL uses the fixture owner; production-role grants are untested.

The actual CapturedARRExecutor, capture replay, processor, validator, PostgresIngestionRepository, PostgresPortalRepository, manual-price coordinator, PostgresOutboxRepository and monthly publisher run. Hotel transport and XML adapter/validation probes remain synthetic; managed object storage uses the filesystem backend. This is real PostgreSQL transaction evidence, not API source equivalence or real cloud-storage/deployment evidence.

Results

ARR_TEST_LOCAL_POSTGRES=1 .venv/bin/python -m unittest -v tests.test_arr_download_postgres_integration

6 cases passed in35.010seconds:

1. Authenticated Web task commits one Finance version and daily-commit outbox event. Two concurrent monthly workers yield one published result and one idle result. Exactly one active monthly version is recorded, with as_of_date2026-09-15. Materialized workbook matches its registered SHA-256; actual formula cells use REAL PRICE×NIGHTS×NO_OF_ROOMS (R*C*G).
2. An actual PostgreSQL transaction commits, its connection is then deliberately closed and a client OperationalError is injected before acknowledgement reaches the caller. Web records interrupted. Queue/executor restart and explicit retry preserve one processing delivery, one Finance version/event and one source/adapter/processor run.
3. Two concurrent real database connections ingest the same frozen envelope before any prior commit. Both acknowledge the same daily_version_id; exactly one delivery/version/event exists. Subsequent executor replay also reuses it.
4. A fixture-only SQL trigger raises XX000 during outbox insertion, after the Finance writes in that transaction. Finance versions/current pointers/records/delivery/event all roll back. Removing the fixture trigger and replaying the original package commits once without recapture or processing again.
5. A real unmatched-price review creates no Finance version or daily event. Saving/finalizing a synthetic manual price commits once, and the Web task reads the same authoritative accepted job as succeeded. Repeated finalization reuses it.
6. After monthly artifacts/version are published, a simulated missing outbox acknowledgement leaves a retryable event. Retry reuses exactly the same report ID and workbook/result artifact IDs and marks the event published.

Without opt-in, all6 cases are skipped and no cluster starts. Fresh schema bootstrap was also checked separately. The cluster and artifact fixtures are stopped/removed in test cleanup. Post-run filesystem/process verification found0 temporary clusters and0 temporary postgres processes. The user preview still reports ready=false. A process-list decoding issue in that read-only cleanup audit was corrected by tolerant decoding; the database/tests were already cleaned normally.

Remaining activation boundary

No real hotel calls or cloud object writes, existing database changes, production restart or subagents occurred. Connection loss is deliberately injected after a confirmed real COMMIT, not a claim of arbitrary network/power-failure durability. Actual runtime credentials/grants/cloud behavior and same-source API mapping remain to be accepted.

The baseline question raised at the end of the SQL validation is now resolved. In this Web task the user reaffirmed Resv.-GEN and supplied res_detail_71054429.XML as the daily file. Independent read-only inspection confirmed72 records for2026-09-15 and byte equality with the earlier sample (SHA2565c87ab6f2483b2244e98e47bb792080ef4aca9036568638842116b246ac97438). CAS/GENERAL are internal XML metadata, not evidence of a different page selection; no change to the user's note scope or further baseline confirmation is needed. See source confirmation. The source task continues to own API mapping. Finish the accepted adapter/independent validator, wire the existing executor, then verify a real chosen day and downstream publication before enabling the button. Do not repeatedly request an unavailable sandbox export. This follow-up changed documentation only, without processing or submitting the sample again.