Repository navigation
fix(microservices): keep nats status updates alive when a listener throws - #18108
Merged
Merged
Conversation
…rows The status loop was started with `void`, so an error thrown while handling a status, e.g. by a listener registered with `on()`, ended the status updates and surfaced as an unhandled rejection, which stops the process by default. Each status is now handled in its own try/catch, and a failing status iterator is logged.
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.
PR Checklist
PR Type
What is the current behavior?
ServerNatsandClientNatsstart their status loop withvoid this.handleStatusUpdates(...). If anything throws while a status is handled, for example a listener registered withserver.on('disconnect', ...)/client.on('reconnect', ...), the loop ends (no further disconnect/reconnect statuses are tracked) and the error becomes an unhandled rejection, which terminates the process with Node's default--unhandled-rejections=throw.Follow-up to #18100, which removed one trigger (
this.options.debugwith no options) but not the weakness itself.What is the new behavior?
try/catch: the error is logged and the loop moves on to the next status.Does this PR introduce a breaking change?
Other information
The diff is mostly re-indentation (
git diff -wshows the actual change). The four new unit tests fail on master (two of them with unhandled rejections).