Fix failed action handling - #1271
Merged
EzraBrooks merged 1 commit intoSep 24, 2026
Merged
Conversation
EzraBrooks
approved these changes
Sep 24, 2026
EzraBrooks
left a comment
Contributor
There was a problem hiding this comment.
This is clearly a better way to do this, thank you.
I dislike/regret the fact that there are still string error messages in this library in general. error here should just be of type GoalError so no string parsing is needed there either. But I guess that's a breaking change and this isn't!
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.
Public API Changes
Adds status and result as additional input variables to user provided failedCallback when using actions.
Description
Currently when an action fails regardless if it is the connection layer or the goal itself the failedCallback is called which only provides me with a stringified version of the result. I do not want to parse strings to identify why my action failed. This adds the goal status and result as additional inputs which I can parse in my code. PR #1103 broke previous behaviour where only failed action due to communication executed the failedCallback callback. It is also possible to simplify this by only providing one callback where the user has to distinguish itself what failed or by restoring previous behaviour that the result is irrelevant for the failedCallback.
Closes #1192