Repository navigation
Wake queued callers after cancelling a pool holder - #54
Merged
josevalim merged 1 commit intoSep 7, 2026
Merged
Conversation
Reconsider pending checkouts after removing a cancelled holder so lazy pools restore progress without another arrival. Cover caller death and callback exit in lazy and eager pools. Await the asynchronous idle-worker termination notification in the existing test. Validate this fork with local mix test.
Member
|
💚 💙 💜 💛 ❤️ |
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.
After a normal borrower crash, queued callers can remain blocked despite available capacity and no active borrower. Progress depends on unrelated future activity, so with an infinite checkout timeout, the wait can be indefinite.
Reproduction
Using a lazy pool, size 1:
Cancellation returns without attempting to serve B.
Expected Behaviour
Cancellation results in B being served in a timely manner.
Discussion
In eager mode, removing the resource schedules an initialisation message that allows the queue to progress. Lazy mode does not schedule that message, so the existing waiter can remain stranded until another event advances the queue.
This change calls the existing
maybe_checkout/1after removing the cancelled caller's resource. It reuses the normal queue, deadline and lazy-initialisation handling. The failed resource is discarded; it is not checked back in or reused.Testing
The four regression cases produce two failures on both v1.1.0 and upstream
main; both lazy cases fail, both eager controls pass. With this change, all four cases pass. The full patched suite passes on Elixir 1.19.2 and Erlang/OTP 28.1.1.Commentary
It is unclear whether this is expected behaviour. If it is, please feel free to close the PR.