Repository navigation
test: retain durable replay denial under contention - #2109
Merged
Merged
Conversation
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 LLVM-instrumented suite observed one successful concurrent scoped delivery and one HTTP 503 refusal, while the test required the loser to return HTTP 409. The replay guard already fails closed with
delivery_replay_unavailablewhen its durable store cannot complete an operation.Keep both requests parallel and require exactly one HTTP 200. Validate the other response as typed replay rejection or typed store unavailability, then resend the identical proof through a fresh router and require HTTP 409
delivery_replayed. This additionally proves durable replay denial after both competing requests have settled. Production code and the existing authorization, tampering, sequential replay and real IPC assertions are unchanged.Validation:
-C instrument-coverage. A warm execution produced three separate nonempty profiles from the same test binary (parent, isolated HTTP child and signed-read child), with all three harness results passing; no coverage-percentage report is claimed.