test: prove production cross-sink sentinel closure - #307
Conversation
️✅ There are no secrets present in this pull request anymore.If these secrets were true positive and are still valid, we highly recommend you to revoke them. 🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request. |
Use production-signed release evidence, exact Redis revocation proof, non-disclosing failures, all-stage cleanup, and canonical NULL-epoch scrub authorization.
1cedf75 to
f28e975
Compare
docs: document combined cross-sink production proof
90763b2
into
architecture/issue-179-context-packet-evidence
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e49a3b46c4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 'task_api', | ||
| 'task_log_api', | ||
| 'task_log_export', | ||
| 'worker_diagnostics', |
There was a problem hiding this comment.
Include queue payloads in the sentinel inventory
The proof can emit S4_CROSS_SINK_PRODUCTION_SENTINEL_OK without creating or inspecting a queue job: this required-contract inventory has no queue entry, and the file contains no queue/enqueue/job path. This leaves regressions that put the seeded prompt, path, or credential into the normal Redis job payload undetected, even though docs/architecture/issue-179-context-packet-evidence.md:3897-3903 requires queue payloads to pass the same omission suite and makes that evidence mandatory. Add the production enqueue/read boundary to this inventory and assert its stored payload.
AGENTS.md reference: AGENTS.md:L28-L33
Useful? React with 👍 / 👎.
| runRedisStep( | ||
| 'cross_sink.redis.legacy_purge_failed', | ||
| () => rawRedisAdapter.purgeLegacyTaskEventKeys(input), |
There was a problem hiding this comment.
Exercise the production Redis error reporter
When a production Redis operation rejects with a credential- or key-bearing message, this test-only runRedisStep wrapper replaces it with a fixed category, so the non-disclosure proof remains green. The real CLI instead passes createLegacyLeakageRedisAdapter(redis) directly at web/scripts/scrub-legacy-leakage.ts:789-790 and prints the original error.message at lines 808-810. Exercise the raw CLI/error path or move the sanitization into production code so the mandatory proof can detect that disclosure.
Useful? React with 👍 / 👎.
Source Issue
Issue: #179
Summary
This child adds the missing combined production proof for PR #198. One fixed hostile corpus passes through the supported Architect artifact, task-log, task-event, API, export, and Server-Sent Events paths while the same run uses disposable PostgreSQL and Redis services.
The Reviewer rework records both required release-evidence arms with an ephemeral Ed25519 key through the production recorder and dedicated database roles. It binds legacy Redis revocation to a freshly reverified authenticated client immediately before deletion, replaces credential-bearing Redis failures with fixed diagnostics, and runs every teardown stage even when another stage fails.
The scrub authorizer follows the canonical release registry: the S4 producers-disabled receipt must have no epoch, and predecessor epoch comparison is null-safe. Numeric epochs remain rejected.
Exact stack
architecture/issue-179-context-packet-evidence1f2bf58dc8bc3aede77e6e7a19124b34db17c16a5c7cfdb66425d42f49f8597f04565ff97aca4421Files in this PR
.github/workflows/web-ci.ymlweb/__tests__/cross-sink-production-sentinel.postgres-redis.test.tsweb/__tests__/epic-172-s4-postgres.test.tsweb/package.jsonweb/scripts/scrub-legacy-leakage.tsThe final workflow correction moves the unchanged pristine cross-sink database clone after migration and role provisioning but before the mutating S4 PostgreSQL proof.
Local evidence
S4_CROSS_SINK_PRODUCTION_SENTINEL_OKemitted exactly once.npx tsc --noEmit, production build, workflow YAML parse, andgit diff --check: passed.Negative and mutation evidence
Checked-in behavior proves invalid signatures, wrong predecessor/receipt binding, forbidden numeric epoch, already-closed client identity, fresh pre-delete binding, nested credential-bearing Redis errors, and simultaneous Redis/PostgreSQL cleanup failures are rejected without trusted evidence, identity deletion, or checkpoint advancement.
A temporary uncommitted mutation reused the stale setup binding instead of calling the fresh binding path. The real combined proof failed at
The cross-sink proof did not reject a stale legacy client binding before revocation., while all-stage cleanup returned PostgreSQL and Redis to zero. The fresh binding implementation was restored and the exact 1/1 proof passed.Isolation and cleanup
Local validation used dedicated disposable PostgreSQL and Redis services. Cleanup attempts every stream, client, ACL, key, database, and environment-restoration stage in fixed order. It preserves the primary failure, reports only fixed cleanup categories, deletes the exact Redis state and ACL users, closes all application/database clients, then drops the dedicated PostgreSQL database and verifies it is absent.
Residual boundary
This child does not change the deferred execution-lifecycle work or operator documentation. PR #308 remains untouched and must be restacked separately after this PR is accepted.
Hosted exact-head status
At
5c7cfdb66425d42f49f8597f04565ff97aca4421, all exact-head gates pass:30504910264, job90752435423: zero-skip unit suite; S4 PostgreSQL 14/14; Redis scrub 3/3; Redis ACL 3/3; combined cross-sink 1/1 withS4_CROSS_SINK_PRODUCTION_SENTINEL_OKemitted exactly once; build, S3 concurrency, disabled-ingress recovery, and E2E all completed successfully.30504910254, job90752435297: passed.90752430273: passed.