A refund that is counted and bounded - #92
Merged
Merged
Conversation
The unclaim path gave a delivery back without limit, so a caller claiming and aborting in a loop could never reach the delivery cap.
The only check on the deliveries was a lower bound, which the refund's absence also satisfies. The contract above it still described the old behaviour, and a release does not share this counter.
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.
UnclaimAsyncundoes a handout whose answer never reached the Runner, and itgave the delivery back without limit. A caller that claims and aborts in a
loop has exactly the shape the delivery cap exists to stop: a job that poisons
every Runner it reaches would be refunded back below the cap for ever and never
fail.
It is now bounded and counted by
Refunds, sharing that counter with thereaper's refund for an unacknowledged reclaim — one counter, so the two paths
that give a delivery back for a handover that did not happen cannot each spend
three. A release stays counted apart in
Releases, with three free of its own,because a release is a Runner saying it is stopping: something was tried and
something did happen.
An assertion the refund can fail
The test's only check on the deliveries was
>= 2, which the refund's absencealso satisfies — so nothing verified that an undone handout gives a delivery
back at all. It is
Assert.Equal(2, deliveries)now, and the number is whatmakes it bite: five claims are made and three are refunded, so two stand. Delete
the refund and every claim counts (five); unbound it and none does (zero).
Both proved by sabotage:
Refunds— expected 3, actual 0Deliveries— expected 2, actual 5The XML contract above the method said the delivery is given back without
counting, which is now the opposite of what it does, and the test's own comment
claimed a release shares this counter. Both corrected.
Verification
dotnet build -warnaserror: 0 warnings, 0 errors. Full suite: 809 passed, 0failed, 2 skipped.