You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 6fdc6f8
Browse filesBrowse the repository at this point in the historyBrowse files
Make the staging rehearsal prove what it cleaned up, not what it remembered
The rehearsal kept two ledgers: everything it created, and a hand-maintained
list of what to delete afterwards. The rejected post was missing from the
second one. Its cleanup check then asked whether each record still read
publicly, and a rejected record returns 404 to everyone by definition — so
the leak was invisible to the very assertion meant to catch it. Every run
left one row in staging and reported cleanup as passing.
That is the shape of failure worth naming: not a missing test, but a test
that could only ever agree with itself. It surfaced on the first nightly
run after the credentials landed, which is roughly the argument for having
put it on a schedule.
Cleanup now walks the ledger that already knows what was created, so
nothing has to be remembered twice, and it finishes by asking D1 whether
any of those rows survived. Records the rehearsal deletes on purpose
return 404 to the delete call, which stays tolerated; a row that is merely
invisible does not.
Verified against staging: the run is green and leaves nothing behind, and
the new query returns the row this morning's run abandoned — so the check
would have gone red on it. That row is now deleted through the audited
endpoint rather than by hand in SQL.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments