feat(watch): propagate SIGINT and SIGTERM signals to function if extensions are registered#853
Conversation
8bbaa45 to
7945904
Compare
…nsions are registered
calavera
left a comment
There was a problem hiding this comment.
This is really cool, thanks for implementing it!
|
@calavera don't suppose you'd be up for a new release once this lands? I have some PRs out to the rust lambdas runtime with some examples that depend on these changes. Would be great to have them work locally out of the box! |
|
I can do a release with these changes on Wednesday. Let me check first if there is anything else I could add to it. |
|
Awesome! Much appreciated. |
|
This pull request has been automatically locked. Create a new discussion if you'd like to continue the conversation. https://github.com/cargo-lambda/cargo-lambda/discussions/new?category=general |
|
Version 1.8.5 released with this patch. |
Closes: #850
Adding some rudimentary signal propagation to allow testing graceful shutdown logic via
cargo lambda watch.As a refresher,
SIGTERMandSIGINTare sent to functions if and only if at least one extension is registered. And then, the delay beforeSIGKILLis 500ms if there is an internal extension registered, or 300ms if only an external.More information can be found here:
https://github.com/aws-samples/graceful-shutdown-with-aws-lambda
My use case is that I want to validate function graceful shutdown logic without relying on opaque AWS decisions on when to kill a running function.
I added some minimalist logic to somewhat mirror the above:
cargo lambda watchprocess, check whether either extension type was set, and return the corresponding shutdown delay if soSIGKILLif not done in time. Either way, clean up thewatchexec.I did NOT implement the following:
watchexecaction outcomes with non-watch-exec logic inbetween, I didn't bother futzing with itSHUTDOWNevents / signals - this would have been much larger scopeThese gaps are documented in the new doc section for this PR. If somebody needs any of those features, presumably they could layer them on top down the road.
Testing
My graceful shutdown testbed was this file.
With my new logic,
Control-C-ing on my watch task in debug mode generated:If I add a second-long sleep (longer than the 500ms delay before SIGKILL), I instead see the shutdown not complete:
Some sort of warn message that time ran out would be nice, but as I mentioned, it's pretty klunky trying to chain non-watchexec logic inside the outcomes, so I didn't bother.
Finally, in a function with NO extensions registered, I don't see graceful shutdown attempted at all: