-
Notifications
You must be signed in to change notification settings - Fork 16
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
Add shutdown. #111
base: main
Are you sure you want to change the base?
Add shutdown. #111
Conversation
753a325
to
35a62fd
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #111 +/- ##
==========================================
- Coverage 81.45% 81.37% -0.09%
==========================================
Files 10 10
Lines 1941 1954 +13
==========================================
+ Hits 1581 1590 +9
- Misses 360 364 +4
Continue to review full report in Codecov by Sentry.
|
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.
The high-level design here looks good, so assuming this works as expected, +1. Thanks!
The `shutdown()` call performs an orderly shutdown and emits events. This differs from the current `exit()` and `process.exit()` behavior which is more immediate.
This does not appear to impact how Bedrock behaves when it receives a |
A
shutdown()
API is added to perform orderly shutdown. This came about due to howbedrock-test
was exiting. In the flow it uses, callingbedrock.exit()
orprocess.exit()
after successful testing results in a more abrupt shutdown. There isn't a way to exit and emit orderly events on the way. In some testing cases you may wantbedrock.exit
or similar events to trigger to do cleanup.This patch attempts to keep the same semantics for current code and only adds the
shutdown()
call (and does some refactoring). Retaining all prior behavior in all cases isn't well tested. Help wanted.shutdown()
could be named something else or be hacked intoexit()
as options, but this seemed like a simple approach. At the time this was written, it wasn't namedstop()
, but now I can't recall the reasoning and that might be a better choice as it aligns with start/stop semantics and event naming. Comments welcome.