Renames max_retries to max_attempts in config#46
Merged
Conversation
Internally max_retires was +1 to get max attempts anyway, this makes it clearer to the end user how many times a pipeline will run
JessF298
approved these changes
May 26, 2026
JessF298
left a comment
JessF298
left a comment
Collaborator
There was a problem hiding this comment.
lgtm - installed and relevant tests pass.
Might consider nicer error handling, either custom errors or as suggestied use the add_note() method on the exception.
rather than rasing another ValueError
Collaborator
Author
|
yeah good point - for polish we can look at custom exceptions at a later date, for now used the we can merge this whenever we are ready to update the configs |
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
2 participants
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.
Addresses #32
Previous behavior wanted a user to set a number of retries allowed. Internally this was always incremented by 1 to get the total number of attempts. This felt unintuitive as a user would have to set 0 if you only wanted one run.
New behavior is to allow the user to set explicitly the number of attempts for a pipeline - and validates at config parse time that this value is >=1.
This is a breaking to change to all configs - which will need to be updated once merged so we can hold off on this until ready.