Avoid crash of event handler causing abnormal shutdown of subscription process#318
Open
xpgdk wants to merge 1 commit intocommanded:masterfrom
Open
Avoid crash of event handler causing abnormal shutdown of subscription process#318xpgdk wants to merge 1 commit intocommanded:masterfrom
xpgdk wants to merge 1 commit intocommanded:masterfrom
Conversation
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.
Whenever we have an event handler that crashes, we have the issue that we get an additional, related, but harmless error from Subscription process.
A small Commanded example to illustrate this:
Let's imagine we have an event handler that crashes with a
RuntimeError. This results in an unhandled exception to be logged:This is all good and expected. However, in addition to this, another unhandled exception is logged:
As the subscription monitors the subscriber (the
Sample.Users.Projectorevent handler in this case), it receives a:DOWN-message, when the subscriber crashes. As part of handling this, the subscription stops with the same reason as the subscriber.The change that I suggest will stop the subscription with reason
:normalregardless of the subscriber termination reason.From what I can tell, this does not have any negative impacts, but will make logs more clear when subscribers crash.