Repository navigation
[uss_qualifier] Remove on_failure - #1776
Merged
BenjaminPelletier merged 3 commits intoOct 7, 2026
Merged
Conversation
BenjaminPelletier
marked this pull request as ready for review
October 7, 2026 09:15
mickmis
approved these changes
Oct 7, 2026
mickmis
left a comment
mickmis
left a comment
Contributor
There was a problem hiding this comment.
LGTM, I agree it is better to remove that.
I think however a mention in the next release notes could make sense for users. Maybe in the optional migration tasks to hint them to remove it, and also warn of the small behavior change that on_failure: Abort is no longer honored.
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.
As part of #1428, this PR removes the "success"-focused
on_failurefromTestSuiteActionDeclaration. After this PR, all existing test configurations will continue to be valid as specification of unrecognized fields is supported by ignoring them (soon_failurewill be ignored). There will technically be some behavioral changes wheneveron_failure: Abortwas specified, but I think triggering the abort logic would usually be more confusing in the current state for the reasons related to "success" mentioned in #1428. All instances ofon_failure: Continuewere redundant specifications and their removal wouldn't even have resulted in behavior change before this PR.