New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Flow Error Handling #17519
Fix Flow Error Handling #17519
Conversation
This partially reverts commit c7e7671.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was curious about that too, but thought that was the intended behavior since the error was just dumped into it before...it just couldn't stringify it because it was enumerable. Which resulted in inconsistent errors because Axios errors some keys are enumerable and some are not. Etc. @rijkvanzanten do you want the full errors returned? |
Are you worried about the paths? In this case we could use https://github.com/sindresorhus/clean-stack to clean up the stack. Edit: Let's not block the pull request by this concern and rather track it separately 👍 |
@paescuj The path i would consider unintended information disclosure yeah but it is also not very readable in this format when all you really need is |
Agree very much! I'm going to create a separate issue for this 👍 |
@br41nslug Not every Operation throws an instance of error, though when it errors. For example, the webhook/request operation. This PR also fixed returning the request instead of the result. The only way to do that with Axios was to make some custom error throwing and catching as a string and then parsing it. Your change breaks the changes made to that. Additionally, in almost every other place, we return errors as JSON objects; however, your change returns a string which may confuse people using flows? |
Thanks @connorsimply I may have been a little overzealous on the friday fix there. Have updated it to only apply in the case of an actual Error and use the existing logic otherwise |
@br41nslug @paescuj Are we good then to merge now? Tested your changes and they LGTM! |
@connorsimply Yep I think so |
This comment was marked as outdated.
This comment was marked as outdated.
Co-authored-by: Pascal Jufer <pascal-jufer@bluewin.ch>
@paescuj Is this clear to be merged now? |
Looks good from my side now 👍 Glad if you could take a final look at it again! 😃 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
* Validate Operation Result is Serializable * Enumerate Flow Error Object so it gets logged * Add ability for error to be a JSON string and parse it * Make the request operation throw useful error * Revert DockerCompose in "Validate Operation Result is Serializable" This partially reverts commit c7e7671. * Fix Typescript Errors * Move isValidJSON to Shared Util and add Tests * return the error message excluding stack trace * allow for non-exception errors * Apply suggestions from code review Co-authored-by: Pascal Jufer <pascal-jufer@bluewin.ch> * Clean-up after wrong suggestion * Clean-up processing of error data * Use content-type json if body is object * Reformat error data check --------- Co-authored-by: Rijk van Zanten <rijkvanzanten@me.com> Co-authored-by: Brainslug <br41nslug@users.noreply.github.com> Co-authored-by: Brainslug <tim@brainslug.nl> Co-authored-by: Pascal Jufer <pascal-jufer@bluewin.ch>
Description
Fixes #15291, Fixes #14415, Closes #16166
This validates that the result of an operation is valid serializable JSON, fixes errors being swallowed because they are enumerable, fixes the request operations error being inconclusive, and adds the ability for operations to throw JSON string errors and them to be parsed before being pushed as an error.
Type of Change
Requirements Checklist
If adding a new feature: