Refs #80 #192 #236 #239 #241 #242 #244.
Current status — hostile concurrency acceptance is GREEN, protected integration still pending
This issue required an explicit real-repository proof that two concurrent divergent PostgreSQL writers cannot both become authoritative. Draft PR #242 executes that acceptance and shows the existing canonical PostgreSQL publication boundary serialized the tested races correctly; no production code/schema repair was required on that predecessor lineage.
Protected/default Wardnet truth has advanced to main@f8260f1e03836039ff9463dd99fa982e4e270c4b; StateAuthority::Postgres remains disabled. #242 is Draft branch evidence only, inherited by descendant #244. Its receipts are historical old-parent evidence until the Runtime Configuration foundation (#140/#310) is synthesized against current protected main and the PostgreSQL dependency stack is non-force-restacked; no predecessor GREEN transfers after parent/head movement.
Current #242 is exact 641d7cd4b12d174015801ce4aee8f29803f239ad, Draft, based on exact #241 recovery head 992d9c366c47515a121b786197c872db81957dcc.
Executed real PostgreSQL hostile acceptance
The test uses real postgres:18.4-bookworm, canonical migrations/roles, an externally managed ordinary runtime LOGIN and a two-member PostgresTenantPool. A setup-only PostgreSQL session holds the exact tenant/source advisory key long enough to prove both runtime writers are concurrently waiting on PostgreSQL's canonical serialization boundary via pg_stat_activity; release is observation-driven rather than sleep-driven.
From the same generation-8 head it exercises:
- same candidate ordinal with divergent generation tokens/evidence/attribution;
- same generation token with divergent immutable evidence/attribution;
- different monotonic candidate ordinals/tokens that both name generation 8 as expected prior;
- one byte-identical duplicate pair as the positive/idempotent control.
For every divergent race, exactly one writer returns Committed, the other returns the stable typed PublicationConflict, the losing command remains conflict on later explicit retry, and durable inspection shows exactly one candidate generation/publication/audit/current-head authority tuple with no loser residue.
For the byte-identical concurrent pair, one writer returns Committed and the other Replay, still with one durable publication/audit/head tuple rather than two commits that merely deduplicate afterward.
A separate held tenant-A chain lock proves tenant B can commit the same source transition through the other physical pool member before tenant A is released. The canonical tenant/source PostgreSQL serialization boundary therefore does not become a global process writer lock. Final unbound probes require both reusable runtime sessions to carry no residual tenant context.
RED / execution evidence
Test-only 6de0b89e2eef493948d5c5d18b0eea46636cfde7 materialized CI 34380847766, rust job 102565029287, but failed only cargo fmt --check; the hostile PostgreSQL test did not execute, so that formatter failure is correctly not treated as a semantic RED.
After applying only the emitted rustfmt result, exact 641d7cd4b12d174015801ce4aee8f29803f239ad completed CI 34381212642, rust job 102566250174, terminal SUCCESS: checkout, exact formatting, locked workspace suite including the real concurrent PostgreSQL acceptance, and strict Clippy all passed. The existing production publication implementation therefore satisfied the hostile contract on that exact predecessor lineage; a source/schema change would be unjustified.
The repository's live fuzz.yml PR path filter does not materialize for this test-only delta because it covers src/**, crates/**, fuzz/** and the workflow itself. Fresh review/thread inventories recorded by the owning PR were zero. These historical receipts must be reacquired on the eventual current-base integration head.
Completion gate
Keep the issue open until #242 or a verified successor carrying this exact real-PostgreSQL concurrency acceptance reaches protected main in the dependency-first PostgreSQL integration. First synthesize Runtime Configuration #140 with current protected-main auth/runtime semantics through #310 (or a verified complete successor), then restack this dependency chain non-destructively and reacquire exact-head evidence. Because the hostile acceptance proved the tested implementation correct, there is no missing production-code delta to manufacture; the valid retained delta is the executable test/evidence itself.
The protected integration candidate must preserve the one-commit/one-conflict and committed+replay invariants, tenant/source rather than global serialization, no loser residue, tenant-context cleanup and no automatic replay of ambiguous work, while also satisfying then-live 100% owned-production coverage/rustdoc, review/thread, security/CodeQL, package/SBOM/provenance/governance and fresh-base requirements. #239 recovery, #243 coverage and aggregate #80/#192 release readiness remain independent prerequisites.
No process/global mutex, process-local writer cache, source churn, force update, destructive rebase, self/model approval, routine bypass, gate weakening, mutable foreign dependency, source copy, cross-service SQL, synthetic-only concurrency, elapsed-time success inference or predecessor-evidence transfer.
Refs #80 #192 #236 #239 #241 #242 #244.
Current status — hostile concurrency acceptance is GREEN, protected integration still pending
This issue required an explicit real-repository proof that two concurrent divergent PostgreSQL writers cannot both become authoritative. Draft PR #242 executes that acceptance and shows the existing canonical PostgreSQL publication boundary serialized the tested races correctly; no production code/schema repair was required on that predecessor lineage.
Protected/default Wardnet truth has advanced to
main@f8260f1e03836039ff9463dd99fa982e4e270c4b;StateAuthority::Postgresremains disabled. #242 is Draft branch evidence only, inherited by descendant #244. Its receipts are historical old-parent evidence until the Runtime Configuration foundation (#140/#310) is synthesized against current protected main and the PostgreSQL dependency stack is non-force-restacked; no predecessor GREEN transfers after parent/head movement.Current #242 is exact
641d7cd4b12d174015801ce4aee8f29803f239ad, Draft, based on exact #241 recovery head992d9c366c47515a121b786197c872db81957dcc.Executed real PostgreSQL hostile acceptance
The test uses real
postgres:18.4-bookworm, canonical migrations/roles, an externally managed ordinary runtime LOGIN and a two-memberPostgresTenantPool. A setup-only PostgreSQL session holds the exact tenant/source advisory key long enough to prove both runtime writers are concurrently waiting on PostgreSQL's canonical serialization boundary viapg_stat_activity; release is observation-driven rather than sleep-driven.From the same generation-8 head it exercises:
For every divergent race, exactly one writer returns
Committed, the other returns the stable typedPublicationConflict, the losing command remains conflict on later explicit retry, and durable inspection shows exactly one candidate generation/publication/audit/current-head authority tuple with no loser residue.For the byte-identical concurrent pair, one writer returns
Committedand the otherReplay, still with one durable publication/audit/head tuple rather than two commits that merely deduplicate afterward.A separate held tenant-A chain lock proves tenant B can commit the same source transition through the other physical pool member before tenant A is released. The canonical tenant/source PostgreSQL serialization boundary therefore does not become a global process writer lock. Final unbound probes require both reusable runtime sessions to carry no residual tenant context.
RED / execution evidence
Test-only
6de0b89e2eef493948d5c5d18b0eea46636cfde7materialized CI34380847766, rust job102565029287, but failed onlycargo fmt --check; the hostile PostgreSQL test did not execute, so that formatter failure is correctly not treated as a semantic RED.After applying only the emitted rustfmt result, exact
641d7cd4b12d174015801ce4aee8f29803f239adcompleted CI34381212642, rust job102566250174, terminal SUCCESS: checkout, exact formatting, locked workspace suite including the real concurrent PostgreSQL acceptance, and strict Clippy all passed. The existing production publication implementation therefore satisfied the hostile contract on that exact predecessor lineage; a source/schema change would be unjustified.The repository's live
fuzz.ymlPR path filter does not materialize for this test-only delta because it coverssrc/**,crates/**,fuzz/**and the workflow itself. Fresh review/thread inventories recorded by the owning PR were zero. These historical receipts must be reacquired on the eventual current-base integration head.Completion gate
Keep the issue open until #242 or a verified successor carrying this exact real-PostgreSQL concurrency acceptance reaches protected
mainin the dependency-first PostgreSQL integration. First synthesize Runtime Configuration #140 with current protected-main auth/runtime semantics through #310 (or a verified complete successor), then restack this dependency chain non-destructively and reacquire exact-head evidence. Because the hostile acceptance proved the tested implementation correct, there is no missing production-code delta to manufacture; the valid retained delta is the executable test/evidence itself.The protected integration candidate must preserve the one-commit/one-conflict and committed+replay invariants, tenant/source rather than global serialization, no loser residue, tenant-context cleanup and no automatic replay of ambiguous work, while also satisfying then-live 100% owned-production coverage/rustdoc, review/thread, security/CodeQL, package/SBOM/provenance/governance and fresh-base requirements. #239 recovery, #243 coverage and aggregate #80/#192 release readiness remain independent prerequisites.
No process/global mutex, process-local writer cache, source churn, force update, destructive rebase, self/model approval, routine bypass, gate weakening, mutable foreign dependency, source copy, cross-service SQL, synthetic-only concurrency, elapsed-time success inference or predecessor-evidence transfer.