Repository navigation
Don't delete a committed log segment when the manifest CAS answers 412 - #103
Open
0bserver07 wants to merge 1 commit into
Open
0bserver07 wants to merge 1 commit into
0bserver07 wants to merge 1 commit into
Conversation
The S3 SDK retries failed calls three times by default and the GCS client retries uploads that carry a precondition, the manifest CAS included. When a CAS lands and its reply is lost, the retry gets a 412 from our own write. process_batch, publish_compact_classified and publish_settings_impl all read any 412 as a lost race and delete their log segment, which the committed manifest now lists: the writer reports a failure for a durable change and every reader then fails on the missing segment. Run the existing cas_landed check on a 412 too before dropping the segment, and keep an unknown outcome unknown when that check fails. The fault store gains the missing fault kind (applied, then 412), sharing the existing CAS roll so seeded simulations keep their sequences, and a test drives a push, a compaction and a settings change through it. One extra manifest GET on the 412 path only. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
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
1 participant
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.
The S3 SDK retries failed calls three times by default, and the GCS client retries uploads that carry a precondition. Both cover the manifest CAS. So if a CAS lands and its reply gets lost, the client retries and the retry gets a 412 from our own write.
process_batchtreats any 412 as a lost race and deletes its log segment, which the committed manifest now lists. The pusher gets an error for a push that actually went through, and every reader after that fails withcorrupt: object not foundon that segment. Compaction and settings publishes do the same thing.The fault store couldn't show this. It can apply a write and then return a retryable error, or return 412 without applying, but not apply and then return 412. This adds that fault (
p_cas_fail_after) and a test that runs a push, a compaction and a settings change through it. On main the push fails withmanifest lists log/0000000000000001.pb but it is gone.The fix runs the existing
cas_landedcheck on a 412 too, before dropping the segment. If our exact segment is listed, the write landed and we report success. If not, it was a real lost race and we drop and retry like before. If the check itself fails, the outcome stays unknown and the segment stays, same as the non-412 path today. That costs one manifest GET on the 412 path only, and I added a row for it to docs/ROUNDTRIPS.md. The new fault shares the existing CAS roll, so the seeded simulations keep their sequences.Turning off the client libraries' own retries for conditional writes would be the other half, which came up on #90. This keeps the publisher correct either way.
Checked with the full local gate (fmt, clippy, unit, crate, server, e2e and sim suites all pass), and by taking out each of the three fixes in turn: the test then fails in that phase.
The red
bounded contract checksjob is the TLA+ pin from #71, not this change.