Says which use options the attempt cap ignores - #142
Merged
Merged
Conversation
The README's "Capping a handler's attempts" section said any :max_attempts value other than a positive integer fails the handler's compile, and the Invoke.Handler moduledoc sentence just before its literal-options paragraph said the same. Neither matched the code: __using__/1 reads the options only when the use argument is a literal keyword list and reads only :max_attempts from it, and __max_attempts__!/2 answers nil for nil. The README now says the options must be a literal keyword list in the use, that a list held in an attribute, a variable or a call is ignored whole, that any other key is ignored, and that max_attempts: nil declares no cap. The moduledoc sentence now defers to the paragraph that follows it. Docs only; no behaviour changes and no changelog fragment (documentation is excluded by changelog.d/README.md). Refs: sob-tfq
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.
Summary
The README's "Capping a handler's attempts" section said any
:max_attemptsvalue other than a positive integer fails the handler's compile, and theStatifierOban.Invoke.Handlermoduledoc sentence just before its literal-options paragraph said the same. Both now match that paragraph:use; a keyword list reaching it through a module attribute, a variable or a function call is ignored whole, as is any argument that is not a keyword list; the one key read is:max_attemptsand any other key is ignored;max_attempts: nildeclares no cap; none of these is an error.No other README section changes. Docs only; no behaviour changes, so no changelog fragment (
changelog.d/README.mdexcludes documentation).Review (in-turn, gate tier)
Each claim was checked against
lib/statifier_oban/invoke/handler.exby anchor:__using__/1reads:max_attemptsonly whenKeyword.keyword?(opts)holds on theuseargument as written, so an attribute, a variable, a call or a non-list argument yields no cap, andKeyword.get/2reads only that key;__max_attempts__!/2answersnilforniland raisesArgumentErrorfor any value that is not a positive integer;put_max_attempts/2adds nothing to the job when the handler's cap isnil. The misspelled-key and non-literal cases are pinned by the tests "an unknown key in the use options compiles clean and stores no cap" and "use options that are not a literal keyword list compile and store no cap" intest/statifier_oban/invoke/handler_test.exs; the bad-value raise by "a cap that is not a positive integer fails the handler's compile". No test compiles a handler with an explicitmax_attempts: nil; that gap is noted for follow-up, not changed here.Gate
The edit is in
lib/, a build path, so the fullmix qualityran green on the rebased head (313 of 313 tests).Refs: sob-tfq