Repository navigation
Settle the pending payload deletion before asserting the bytes are gone (#970) - #997
Merged
Merged
Conversation
…ne (#970) Cleanup commits the object's last registration together with a durable deletion intent, and deletes the bytes after that commit. On SQLite the after-commit step can lose the write lock to the writer the test has just released; it then keeps the intent for the next cleanup pass, as designed. The test asserted the bytes were gone immediately, so it failed intermittently on unrelated PRs. Bytes may now outlive the commit only with exactly that intent pending. The test runs the retry pass, as the other retention tests do, then requires both the bytes and the intent to be gone. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Member
Author
|
Tier C receipt. Hosted checks are terminal at exact head |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Review tier C: test only. It changes one PHPUnit helper and no application code.
Fixes #970.
Cause
WorkflowStreamPayloadRaceTest::test_a_writer_and_payload_cleanup_decide_a_shared_object_under_its_lockfailed three times on PRs that don't touch PHP: #943, #965 and #995. Each failure was a SQLite cleanup-first case with the same assertion: the shared object's file still existed. Before that assertion, cleanup had reported the object deleted and the writer had been refused.Cleanup doesn't delete the bytes inside its transaction.
RuntimeExternalPayloadDeletions::stagecommits a durable deletion intent together with removing the last registration, and the provider deletion runs in an after-commitflushPending. If that step fails, it catches the error and keeps the intent for the next cleanup pass (retryPending), by design.In these cases the test releases the writer just as cleanup commits. On SQLite the writer's lock-taking write can commit between
flushPending's read and its write, which makes the write fail at once with a busy-snapshot error. The bytes then wait for the next pass, but the test asserted they were already gone. I haven't observed the busy error directly in CI; the fault injection below reproduces the exact symptom through that path.Change
assertObjectDeletednow allows the bytes to outlive the commit only when exactly one deletion intent for that URI is pending. It then runsretryPending('default', 10), asExternalPayloadRetentionRollbackTestalready does, and requires:This is stricter than before in one respect: the intent row must also be cleared.
Evidence (lab2, the repo's
baseimage, SQLite data sets)flushPendingfail once, in the container's copy only. On thesqlite: http append, run prune firstdata set:Failed asserting that file ".../avro/3c/3ccdc67e…" does not exist;🤖 Generated with Claude Code