-
Notifications
You must be signed in to change notification settings - Fork 230
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
Allow errors in signal interceptors #564
Conversation
@@ -2249,7 +2249,7 @@ func (env *testWorkflowEnvironmentImpl) signalWorkflow(name string, input interf | |||
panic(err) | |||
} | |||
env.postCallback(func() { | |||
env.signalHandler(name, data) | |||
_ = env.signalHandler(name, data) |
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'm curious, this seems like a JetBrains-ism, is it? I don't think any traditional go tools have any problem with ignoring these returns.
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.
We have errorcheck linter, which complains if you ignore an error.
What was changed
Allowed errors in signal interceptors.
Why?
Previously there was no way to return an error from the signal interceptor, meaning that even if there is a problem signal would be processed anyways and it was impossible to interrupt the flow. This can be a problem in case if interceptor is doing some non-optional operations that have a chance to fail (e.g. network interactions).