open-feature / open-feature/go-sdk
[FEATURE] Init and Shutdown functions should take `context.Context` parameter
- Dominant language
- Go
- Stars
- 250
- Forks
- 62
- Avg merge
- 2d 3h
- Merged PRs (30d)
- 25
Description
### Requirements
The StateHandler interface defines two functions: Init and Shutdown.
https://github.com/open-feature/go-sdk/blob/dd4cf71f8226026a71d51d1edcfd1026c965be15/openfeature/provider.go#L64-L67
There is also a top-level Shutdown function:
https://github.com/open-feature/go-sdk/blob/dd4cf71f8226026a71d51d1edcfd1026c965be15/openfeature/openfeature.go#L90-L92
[Section 2.4 of the specification](https://openfeature.dev/specification/sections/providers#24-initialization) says the following (emphasis mine).
> Many feature flag frameworks or SDKs require some initialization before they can be used. They might require **the completion of an HTTP request, establishing persistent connections, or starting timers or worker threads**. The initialization function is an ideal place for such logic.
The types of initialization mentioned above normally require a `context.Context` parameter to be passed. For example, to make an HTTP request, one most definitely should be passing a `context.Context` parameter.
As for Shutdown, a context can be used to manage timeouts or cancellation.
The context is also the mechanism through which OpenTelemetry spans and other request-scoped values are propagated. If there is any chance at all that a provider author might perform I/O in the Init and Shutdown functions, then these functions need to have a context parameter.
The `context` [package documentation](https://pkg.go.dev/context) has more details on what contexts are used for and where they should be used.
I propose that the Init and Shutdown functions linked at the top take a `context.Context` parameter for the reasons outlined above. While this is a breaking change, I think it is acceptable given that both [section 2.4](https://openfeature.dev/specification/sections/providers#24-initialization) and [section 2.5](https://openfeature.dev/specification/sections/providers#25-shutdown) of the specification are currently experimental.
Contributor guide
Research direction
Start with openfeature/provider.go lines 64-67 and openfeature/openfeature.go lines 90-92 to inspect the Init and Shutdown declarations. Read their call sites and run the package tests to identify the affected API surface; done means both StateHandler methods and the top-level Shutdown function accept context.Context consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100