Skip to content
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: handle Event signals gracefully #148

Merged
merged 1 commit into from
Aug 16, 2023
Merged

Conversation

subpop
Copy link
Collaborator

@subpop subpop commented Aug 1, 2023

Return errors when handling Event signals emitted by workers and handle
the optional 'message' parameter gracefully.

Signed-off-by: Link Dupont link@sub-pop.net

@subpop subpop requested a review from jirihnidek August 1, 2023 16:30
@subpop subpop force-pushed the better-signal-handling branch from 99ea483 to 9d87852 Compare August 8, 2023 12:16
Copy link
Contributor

@jirihnidek jirihnidek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, it looks good. 👍 I have few comments and suggestions.

internal/work/errors.go Outdated Show resolved Hide resolved
internal/work/errors.go Outdated Show resolved Hide resolved
internal/work/dispatcher.go Outdated Show resolved Hide resolved
internal/work/dispatcher.go Outdated Show resolved Hide resolved
internal/work/dispatcher.go Outdated Show resolved Hide resolved
internal/work/dispatcher.go Outdated Show resolved Hide resolved
internal/work/dispatcher.go Outdated Show resolved Hide resolved
Return errors when handling Event signals emitted by workers and handle
the optional 'message' parameter gracefully.

Signed-off-by: Link Dupont <link@sub-pop.net>
@subpop subpop force-pushed the better-signal-handling branch from 9d87852 to b48c499 Compare August 16, 2023 14:17
@subpop
Copy link
Collaborator Author

subpop commented Aug 16, 2023

I took a different approach towards unpacking a signal into a WorkerEvent. I dropped the two global variables; they weren't useful without adding variability to them, and after that happens, there is no reason to keep global error variables at all. I renamed the unpack error into a more descriptively named "typeConversionError", since that's more accurately describing what the error carries. I dropped the error checking for signal name and parameter length. Looping over the body slice and attempting to convert the interface{} types to their appropriate types will catch any errors that might exist from incorrect signal bodies.

Copy link
Contributor

@jirihnidek jirihnidek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, Thanks for update

@jirihnidek jirihnidek merged commit 2ff6bef into main Aug 16, 2023
@jirihnidek jirihnidek deleted the better-signal-handling branch August 16, 2023 15:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants