Problem
The committed make e2e-isolation gate is nondeterministic at the approval-expiry negative control. One observed run failed with:
expired approval consume error = <nil>
The same unchanged gate passed immediately before this run.
Regression context: #299. Parent: #23.
Root cause
The production consumption predicate correctly uses PostgreSQL statement_timestamp(), but the integration fixture seeds its expired grant from the host clock:
approved_at = time.Now().UTC().Add(-10 * time.Minute)
The row constraint derives expires_at = approved_at + 10 minutes, which puts expiry at approximately host now. If the container database clock is even slightly behind the host, PostgreSQL still sees statement_timestamp() < expires_at and validly consumes the supposedly expired fixture.
This is a test-clock race, not evidence that the atomic production expiry predicate failed.
Required fix
- Seed temporal negative controls from the database clock, not the host clock.
- Put the expired fixture safely beyond the boundary while preserving the exact 10-minute row constraint.
- Keep the pre-approval fixture safely in the future.
- Prove expiry boundary behavior and verify refusals leave the row unconsumed and append no lifecycle event.
- Run the PostgreSQL approval test repeatedly and keep the full isolation gate green.
- Do not weaken the production half-open interval or add caller-controlled time.
Acceptance criteria
Security and cost
Production remains database-clock authoritative with the atomic predicate approved_at <= statement_timestamp() AND statement_timestamp() < expires_at. The fix is test-only and adds no runtime or cloud cost.
Found while validating #303; keep this repair in a separate PR so the observed-only Git snapshot contract stays reviewable.
Problem
The committed
make e2e-isolationgate is nondeterministic at the approval-expiry negative control. One observed run failed with:expired approval consume error = <nil>The same unchanged gate passed immediately before this run.
Regression context: #299. Parent: #23.
Root cause
The production consumption predicate correctly uses PostgreSQL
statement_timestamp(), but the integration fixture seeds its expired grant from the host clock:approved_at = time.Now().UTC().Add(-10 * time.Minute)The row constraint derives
expires_at = approved_at + 10 minutes, which puts expiry at approximately hostnow. If the container database clock is even slightly behind the host, PostgreSQL still seesstatement_timestamp() < expires_atand validly consumes the supposedly expired fixture.This is a test-clock race, not evidence that the atomic production expiry predicate failed.
Required fix
Acceptance criteria
make e2e-isolation, repository CI, release, and real-cluster gates remain green.Security and cost
Production remains database-clock authoritative with the atomic predicate
approved_at <= statement_timestamp() AND statement_timestamp() < expires_at. The fix is test-only and adds no runtime or cloud cost.Found while validating #303; keep this repair in a separate PR so the observed-only Git snapshot contract stays reviewable.