-
Notifications
You must be signed in to change notification settings - Fork 35
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
[Question] API.shutdown()
required in Go?
#189
Comments
I think that's reasonable |
Both solution are fine for me, but from the provider point of view it is always a bit tricky to have specificity for one language. I would prefer to have the same pattern everywhere. If we want to go with the context approach I think we need to be extra cautious to make it explicit in the documentation how we expect providers to handle this. |
I am also fine with language-specific implementations to handle the shutdown (context VS shutdown method). After going through the spec, I think we should keep the keyword
Also, requirement section
Altogether, if we agree on this, then we should correct both API & Provider spec sections to align. |
I like this proposal. |
@toddbaert this can be closed now as you already merged #193 |
1.6.1 requires an
API.shutdown()
function. After a few discussions with contributors I'm not 100% sure this is necessary, particularly for Go.The purpose of the
API.shutdown()
function is for providing a means to initiate a graceful shutdown. For example, in Java, you'd catch a SIGINT in your Java app, and then that handler would callAPI.Shutdown()
to cleanup all the polling, DB connections, workers, and flush telemetry or whatever other cleanup providers need done.However in Go, the Context provides some of this functionality. A better pattern for Go might be to create a provider with a
NewMyProvider
function (which the provider author defines) which takesContext
. That provider listens for ctx.done() and handles their own shutdown. Application authors simply emit the cancellation event and everything is cleaned up.We may want to relax
1.6.1
m making it a "MAY" instead of a "MUST", and add some non-normative text like:@open-feature/sdk-golang-approvers @open-feature/sdk-golang-maintainers
The text was updated successfully, but these errors were encountered: