-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat(run): provides RunWithGracefulShutdown #564
Conversation
f8a9f4a
to
f66f10b
Compare
func Run(fn func(context.Context) error, options ...Option) (err error) { | ||
ctx, cancel := signal.NotifyContext(context.Background(), syscall.SIGINT, syscall.SIGTERM) |
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.
Old implementation makes a hard bond between the root context and SIGTERM
, which means when a SIGTERM
is received, the ctx
will be canceled directly and user has no control of it.
New implementation breaks the bond, see trapShutdownSignal()
for details. Taking some ideas from this post. https://medium.com/over-engineering/graceful-shutdown-with-go-http-servers-and-kubernetes-rolling-updates-6697e7db17cf
// (default as 30 seconds) above this value to make sure Kubernetes can wait for enough time for graceful shutdown. | ||
// More info see here: | ||
// https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-terminating-with-grace | ||
const gracefulShutdownMaxGracePeriod = time.Second * 10 |
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.
Using 10 seconds here as in our preferred CloudRun environment the terminationGracePeriodSeconds
seems not configurable and a fixed 10s is specified in the CloudRun doc.
https://cloud.google.com/run/docs/container-contract#instance-shutdown
Perhaps I should put this in the comment as well.
f66f10b
to
d916cd3
Compare
So to allow user easily wire up a clean up function that can be called BEFORE the root context is done.
d916cd3
to
a6d33d6
Compare
Hey @liufuyang! We've recently run into similar issues that this PR attempts to solve, and we've merged a very preliminary solution in #585. It does not solve the use-case for some things that you are aiming to solve in this PR however, like pull-based PubSub cloudrun instances. There's work planned to implement those fixes down the line as well, so I'll keep you in the loop on how that goes with an upcoming ADR where we can discuss if that solution approaches a solution for your usecase. For now as I think we're gonna take that implementation in a different direction than these proposed changes, I'll close this PR and we can move the future discussions over to #563. Thanks again! |
So to allow users easily wire up a clean-up function that can be called BEFORE the root context is done.
closes #563
So with typical cloudrunner code initiated like this:
Before:
Output when cancel the process:
Note
Noticing it says
Root context is already done, cannot use client anymore.
After:
Output when cancel the process:
Note
Noticing it now says
Root context is still live.