You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basically if the last step didn't throw, we call the run a success. Even if there's a fail in the middle somewhere.
We usually assume that if there was an error but the last step succeeded, then the error was handled and all is well.
But! A common use case is to send an email on error. But if the email step succeeds, you still want to consider the run a fail. This run did not recover, it failed and reported the fail. Its misleading to call this a success.
So in my error reporting step, I need to say "Send the email and then return an error". And probably the final error needs to be the upstream error.
Right now you would probably do this by throwing the downstream error. Kind of awkward - you have to find the right error on state based on the job name (or job id?). And the throw is kinda weird itself.
So (and this has come up before): we need maybe a common helper called exit(). If you exit without an error, we'll stop the whole workflow with success (regardless of everything else that happened. If you exit with an error, that error will be used to force a fail.
We might also want a helper to make it easy to load an error object (getLastError() seems nice)
The text was updated successfully, but these errors were encountered:
When a workflow runs, we generate an exit reason.
Basically if the last step didn't throw, we call the run a success. Even if there's a fail in the middle somewhere.
We usually assume that if there was an error but the last step succeeded, then the error was handled and all is well.
But! A common use case is to send an email on error. But if the email step succeeds, you still want to consider the run a fail. This run did not recover, it failed and reported the fail. Its misleading to call this a success.
So in my error reporting step, I need to say "Send the email and then return an error". And probably the final error needs to be the upstream error.
Right now you would probably do this by throwing the downstream error. Kind of awkward - you have to find the right error on state based on the job name (or job id?). And the throw is kinda weird itself.
So (and this has come up before): we need maybe a common helper called
exit()
. If you exit without an error, we'll stop the whole workflow with success (regardless of everything else that happened. If you exit with an error, that error will be used to force a fail.We might also want a helper to make it easy to load an error object (
getLastError()
seems nice)The text was updated successfully, but these errors were encountered: