[P0] Bound PostgreSQL half-open network loss without replaying started work

[seonghobae]

Refs #80 #192 #229 #230 #232 #234 #235 #236 #239 #240 #241 #242 #244.

Current exact state — refreshed 2026-09-20 KST

The originally identified half-open PostgreSQL protocol-progress defect has a causal Draft repair in PR #244. Protected/default Wardnet truth remains main@f8260f1e03836039ff9463dd99fa982e4e270c4b; StateAuthority::Postgres remains disabled.

PR #244 remains Draft at exact 91cab184c95984d5ffdb6b2a4eb8f8920fbae8f5, based on exact #242 641d7cd4b12d174015801ce4aee8f29803f239ad. The wider PostgreSQL stack is parked behind canonical Runtime Configuration #140, now exact 99c7c6c798f13c9c37d00d9f586f102585ad3494, directly based on protected main, mechanically mergeable and still Draft. The earlier protected-base synthesis/reconciliation lineage is integrated into that root; repository-owned CI/Fuzz/SAST/Security evidence is terminal GREEN, while delegated CodeQL terminal settlement remains central .github#1929 ownership. Do not restack #244 or intermediate PostgreSQL children until #140 satisfies live review/governance and reaches protected truth through normal integration; every adoption must be ordinary/non-force and reacquire exact-head evidence.

Executed RED and minimum causal GREEN for the half-open defect

The real postgres:18.4-bookworm fixture uses canonical migrations/roles, an externally managed ordinary runtime LOGIN, and a two-member pool behind a loopback TCP/protocol fault proxy. It first establishes distinct backend PIDs and a slow-but-valid control, then withholds backend protocol progress while keeping selected client TCP sessions open.

The executed RED proved that a driver-known-open client could miss a PostgreSQL protocol response and remain selected while replacement startup was blackholed, consuming the later checkout budget and leaving a protocol-desynchronised session lifecycle unresolved. Fixture review also corrected the selective schedule so the next round-robin checkout encounters the blackholed member first instead of accidentally exercising the healthy peer.

The minimum production repair changes only Wardnet's PostgreSQL pool/session-liveness boundary:

• pool slots are Option<Client> behind the existing per-slot mutex;
• each driver-known-open session completes bounded, non-mutating Client::check_connection() before Wardnet state work;
• failed/timed-out preflight removes/drops the client before the slot mutex is released;
• one stale slot retains one replacement authority without a global writer lock/reconnect storm;
• one fixed checkout/readiness window is shared across candidate sessions, so a half-open member cannot consume the full budget while a healthy member exists;
• no query/transaction/publication/rollback/COMMIT is automatically replayed after Wardnet database work begins; [P0] Reconcile ambiguous PostgreSQL publication commit without unsafe replay #235/test(state): prove ambiguous PostgreSQL publication commit recovery #236 CommitOutcomeUnknown semantics remain unchanged.

Hostile acceptance proves selective failover, all-stream fail-closed PoolUnavailable, bounded recovery after clearing the fault, no tenant-context residue, no reconnect storm and the slow-valid positive control.

No explicit database lock or long-lived transaction may remain open across LLM calls, external I/O, sandbox execution or long-running computation. Read bounded state and end the transaction, perform slow work outside the transaction, then open a bounded write transaction and revalidate the required optimistic/concurrency predicate before commit. Cross-service SQL remains forbidden.

Buyer-path performance evidence

On exact #244, the real PostgreSQL buyer-path acceptance executes 200 unexcluded probe_unbound_context() samples through the loopback proxy. Each includes PostgreSQL protocol preflight plus the actual probe query. Acceptance requires p95 <=20 ms, preserves unbound tenant context and requires exactly the original two physical runtime sessions so reconnect churn cannot manufacture the result.

Historical exact #244 CI 34402494574 and Fuzz 34402494583 are terminal SUCCESS on 91cab184c95984d5ffdb6b2a4eb8f8920fbae8f5. They prove the causal implementation only and do not transfer after root/base movement.

Remaining exact-head completion gate

The half-open defect is causally repaired on #244, but the issue stays open because Wardnet requires explicit machine-verifiable 100% owned-production statement/line, branch, edge and public-rustdoc completeness on one unchanged exact integration candidate. cargo test/CI success is not a substitute.

docs/TEST_STRATEGY.md on #244 records that distinction and the real PostgreSQL hostile/performance denominator. Do not introduce a duplicate Wardnet leaf coverage workflow merely because central evidence materialization is delayed.

Close only when #244 or a verified complete successor reaches protected main after dependency-first non-force restack and one unchanged integration candidate has explicit 100% owned-production statement/branch/edge/rustdoc evidence, current review/thread evidence, fresh protected-base compatibility and every then-live deterministic/security/SAST/CodeQL/package/SBOM/provenance/governance gate terminal-valid. Model/bot review remains advisory, not independent approval.

This issue does not authorize production PostgreSQL authority. #80/#192 still require complete protected integration, production backup/WAL/storage/encryption/IAM authority, recovery/SLO evidence and immutable release identity.

Traceability

• PostgreSQL Global Development Group. (2026). PostgreSQL 18 documentation: Connection settings. https://www.postgresql.org/docs/18/runtime-config-connection.html
• PostgreSQL Global Development Group. (2026). PostgreSQL 18 documentation: Database connection control functions. https://www.postgresql.org/docs/18/libpq-connect.html
• tokio-postgres 0.7.18. Client::check_connection. https://docs.rs/tokio-postgres/0.7.18/tokio_postgres/struct.Client.html
• Eggert, L., & Gont, F. (2009). TCP User Timeout Option (RFC 5482). https://www.rfc-editor.org/rfc/rfc5482

No force update, destructive rebase, self/model approval, routine bypass, gate weakening, mutable foreign dependency, source copy, cross-service SQL, no-op workflow churn, automatic replay of started work, elapsed-time success inference or predecessor-evidence transfer. Generic solo-maintainer approval remains central .github#772; runner/OpenCode control-plane defects remain .github#712/#1234; delegated CodeQL settlement remains .github#1929 or verified successors.

[seonghobae]

Current implementation receipt — Draft #244@198c1b47c897c4654d9494aeec33070af4549640 on exact parent #242@641d7cd4b12d174015801ce4aee8f29803f239ad now satisfies this issue's branch-level hostile acceptance without enabling PostgreSQL authority.

Verified semantic RED was exact d5602342382da3fcd51086ed13134be843a2ed5e, CI 34385023959 / rust 102579013733: after an all-stream blackhole was cleared, checkout still returned PoolUnavailable because a timed-out protocol preflight had left a desynchronized client occupying its slot while replacement startup was blackholed. Fresh review also corrected the selective fixture so it blackholes the actual next round-robin member rather than an unrelated stream.

Minimum production repair a2b7fc47058ad29d80f699a6bb3599d48f511e86 stores each slot as Option<Client> under the existing per-slot mutex, performs bounded non-mutating Client::check_connection() before Wardnet state work, removes/drops a failed or timed-out client before releasing the slot, and lets one later checkout replace it under the same slot authority. The fixed 500 ms readiness budget is divided across remaining candidates; there is still no generic timeout/replay around a started query, transaction, publication, rollback or COMMIT, and #236 CommitOutcomeUnknown remains unchanged.

Current exact 198c1b47... also adds 200 unexcluded buyer-path probe_unbound_context() samples through the same loopback proxy, including protocol preflight plus the actual query, requiring p95 <= 20 ms, no tenant residue and exactly the original two physical sessions so the result cannot pass by reconnect churn. Exact CI 34388202520 and Fuzz 34388202810 are terminal SUCCESS; submitted reviews and inline threads are zero.

Keep #243 open until #244's valid delta reaches protected truth through the prerequisite stack and current-head governance/required workflows are reacquired. Branch GREEN is not protected integration or release authority.

[seonghobae]

Fresh successor verification — 2026-09-10 KST.

Draft successor #244 remains exact 91cab184c95984d5ffdb6b2a4eb8f8920fbae8f5 on unchanged exact parent #242 641d7cd4b12d174015801ce4aee8f29803f239ad. Production src/postgres_state.rs is unchanged from causal repair a2b7fc47058ad29d80f699a6bb3599d48f511e86; predecessor 198c1b47c897c4654d9494aeec33070af4549640 evidence is historical and does not transfer.

The documentation finding is repaired on this exact head: canonical docs/TEST_STRATEGY.md binds Wardnet's exact-head format/locked-test/strict-Clippy/Fuzz contract, real PostgreSQL 18.4 half-open schedules, one-slot replacement authority, no automatic replay after database work begins, #236 CommitOutcomeUnknown, 200 unexcluded buyer-path preflight+probe samples at p95 <=20 ms, recovery/operability ownership, and explicit 100% owned production statement/branch/edge/rustdoc evidence rather than inferring coverage from cargo test. The traceability section distinguishes final NIST SP 800-218 / SSDF 1.1 from the still-Initial-Public-Draft SP 800-218 Rev. 1 / SSDF 1.2 status and links PostgreSQL 18, tokio-postgres and RFC 5482 authorities.

Fresh exact-current CI 34402494574 and Fuzz 34402494583 are now terminal SUCCESS. This exact head therefore has current format/tests/Clippy/Fuzz plus the hostile half-open and 200-sample buyer-path performance acceptance.

Do not close this issue yet. The remaining complete-close requirement is explicit exact-head 100% owned production statement/branch/edge/rustdoc evidence. That evidence did not materialize as a separate applicable coverage/rustdoc gate on this stacked Draft topology and must not be fabricated, inferred from passing tests, or replaced with a duplicate leaf workflow. The sole product-gap ledger remains #130; update it only from that existing single-writer branch.

Any head/base movement invalidates these receipts. No no-op dispatch churn, gate weakening, predecessor-evidence transfer, self/model approval or routine bypass.

[seonghobae]

2026-09-12 KST dependency-state correction. The half-open PostgreSQL protocol-progress RED→GREEN contract remains unchanged; this comment supersedes the stale foundation snapshot in the body.

Runtime Configuration root #140 is now exact 0c678a924e3bf6ecdd248167e4289c1cbff60688 against protected/default main@f8260f1e03836039ff9463dd99fa982e4e270c4b. Protected #155 credential semantics are already causally reconciled in src/credentials.rs; reverse-direction #310 now has only src/lib.rs as the remaining semantic conflict. #140's current Noema 34620116801 and dynamic CodeQL 34620114135 are SUCCESS, but combined repository Rust/hostile-suite/coverage/rustdoc GREEN must be reacquired after that conflict is resolved.

#244 therefore remains implementation evidence on the old parent chain, not fresh protected-base compatibility. Preserve its real PostgreSQL half-open/preflight/failover/no-replay and 200-sample p95 contract unchanged; after #140 reaches protected truth, restack the PostgreSQL chain dependency-first/non-force and reacquire exact-head evidence before this issue can close.

[seonghobae]

Fresh prerequisite status correction — 2026-09-16 KST: #430 has reached the hostile Runtime Configuration/authentication assertion; it is not merely queued. Fuzz 35029440921 is terminal SUCCESS. CI 35029440905 / rust job 104584220679 established semantic RED when stale run_from_env bound public 0.0.0.0:44429 and returned success without write-capable administrator authority, with protected-auth helpers simultaneously reported as non-test dead code. The 100% owned-production statement/branch/edge/public-rustdoc completion gate remains downstream of the minimum causal src/lib.rs synthesis and the foundation-first PostgreSQL restack. Do not treat any old-parent coverage receipt as current or restack dependents before unchanged-head Runtime Configuration/auth GREEN.

[seonghobae]

Fresh foundation status correction — 2026-09-16 KST

The Runtime Configuration prerequisite has advanced beyond the queued state recorded in the issue body. #140 remains exact 7d98725cc51b259b0be940385b2245758d098081; #430 remains exact 062ea6ab787d0a1d864e429a95f7ed1642fbf37e. Fuzz 35029440921 is terminal SUCCESS. CI 35029440905 / rust job 104584220679 is semantic RED: stale run_from_env bound public 0.0.0.0:44429, printed readiness, and returned success without write-capable administrator authority. The same run exposed the protected-auth helpers as live dead code in this stale synthesis.

#244's existing half-open PostgreSQL repair/p95 receipts therefore remain old-parent implementation evidence only. Do not restack #244 or intermediate PostgreSQL children until #140/#430 reaches one unchanged exact synthesized GREEN head against current protected main; then adopt each parent non-force in dependency order and reacquire exact-current coverage/rustdoc/security/review/base evidence.

[seonghobae]

Status correction — 2026-09-16 KST: the Runtime Configuration foundation is not merely awaiting #430 execution. #430 exact 062ea6ab787d0a1d864e429a95f7ed1642fbf37e established repository-native semantic RED: Fuzz 35029440921 is SUCCESS; CI 35029440905 / rust job 104584220679 passed checkout/toolchain/format and then proved a public bind succeeds without a write-capable administrator on stale #140 run_from_env. Minimum causal repair remains the bounded #310 src/lib.rs synthesis with protected #155 pre-bind auth semantics. This does not change this issue's coverage contract: normal cargo test or predecessor receipts are still not proof of 100% owned-production statement/line, branch, edge and public-rustdoc coverage, and the coverage gate must be reacquired only after the foundation and durable-state stack are restacked normally onto one unchanged current head.

[seonghobae]

Fresh foundation-state correction, 2026-09-17 KST: the body’s Runtime Configuration paragraph is stale. #430 is no longer helper-only cc8f721...; current exact is 65b887e347d47e3cd29071342c353408c3f14e4a. Bounded one-shot synthesis 35160876925 completed SUCCESS, committed only src/lib.rs (0e0f01efbd6e21874c94eed987192534e234f211), and the temporary helper was removed by ordinary fast-forward. Fresh exact-current CI 35180770661 and Fuzz 35180770659 remain QUEUED, so this remains construction evidence only. Do not restack #244 or intermediate PostgreSQL children until #430 normally integrates into #140 and #140 is non-force reconciled with protected main; the half-open repair’s historical exact GREEN remains implementation evidence, not current integration admission.