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

Improve error handling #100

Merged
merged 5 commits into from
Jul 14, 2021
Merged

Improve error handling #100

merged 5 commits into from
Jul 14, 2021

Conversation

MSE99
Copy link
Contributor

@MSE99 MSE99 commented Jul 12, 2021

Checklist

Description

Closes #95

This PR improves error handling, it will make the plugin wait until Redis instance fires ready event before calling the next function, it will also listen to the error event and propagate errors in case anything goes wrong on initial startup.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

I don't think this would work well as it would make call next twice/after boot is completed if the there is an error in the connection later on.

@mcollina
Copy link
Member

I think you need to remove the 'error' handler after 'ready' is emitted.

@MSE99
Copy link
Contributor Author

MSE99 commented Jul 12, 2021

My bad, i thought it was possible to use the next function to propagate errors to fastify even after registering the plugin. removing the error event listener would mean that the user would have to manually close the client themselves after an error occurs.

@MSE99 MSE99 changed the title Improve error handling after startup Improve error handling Jul 12, 2021
Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

Can you please not return the client?

index.js Outdated
} else {
next()
const onError = function (err) {
client.quit(() => next(err))
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think we should quit the client on the first error. In this case we are avoiding the retry strategy that is really important imho.
If we want to go with this event path I think we need to manually handle the retry strategy.

}

next()

This comment was marked as resolved.

Copy link
Member

@climba03003 climba03003 Jul 13, 2021

Choose a reason for hiding this comment

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

When specified lazyConnect, the if clause will stop at return client and next is not reachable.

Copy link
Contributor

@valerio-pizzichini valerio-pizzichini left a comment

Choose a reason for hiding this comment

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

👍 LGTM

index.js Outdated
// Any other errors during startup will
// trigger the 'end' event.
if (err instanceof Redis.ReplyError) {
this.emit('end', err)
Copy link
Member

Choose a reason for hiding this comment

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

I would prefer if we did not call emit() on an object we do not maintain. Just call the onEnd() function.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

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

lgtm

@mcollina mcollina merged commit 37e1fc1 into fastify:master Jul 14, 2021
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.

Connection errors are silent
4 participants