-
Notifications
You must be signed in to change notification settings - Fork 41
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
call close handler with correct parameters #56
call close handler with correct parameters #56
Conversation
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.
Can you add or update the unit tests?
I removed the conditions. There is no case to test I think. |
I would rather not regress this. Can you add a case similae to the example you added in for fastify? |
This test fails on the previous code. |
I also fixed the example #55 |
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.
LGTM
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 not sure this is the best thing to do.
Why you should call close
more than one time?
IMHO if a user calls close
twice there are two options:
E_TOO_MANY_BEERS
🍻- there is some error in its logic.
I think that if a user calls close
more than one time we should log a working and ignore the command or throw an exception.
Thoughts?
I agree with you that this is not an easy to understand behavior, but changing it would be semver-major and I prefer to have it fixed it right now. It's not a big change. |
Only if we throw an error. Log a warning and ignore the command is not, because the user has already called |
The user expected the callback to be called. |
@delvedor In my opinion, it's fine since we are working everywhere with queues. If you can explain it well to the user then it's an easy task.
or they split its shutdown routines into several pieces? |
Ok, then we can call it instantly with an error, such as app.close(err => {
console.log(err) // null
})
app.close(err => {
console.log(err) // 'Closing procedure already started'
}) |
@StarpTech what does it mean? You want to close only a part of your application and sometimes after another part? |
The approach you describe in #56 (comment) is correct. However it's a semver-major change, and I would prefer to land this first as a minor/patch. |
@delvedor just realized that Let's discuss this behavior after this PR. This PR will fix a bug in the close handler specification. |
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.
LGTM
I see it more as a bugfix than a major change. |
No description provided.