feat: eventing implementation

[Kavindu-Dodan]

This PR

Covers the initial implementation of #186

⚠️ Note that, this implementation does not cover the 1 to N relationship requirement of provider to named client requirement (i.e - single instance of a provider can be bound to multiple names, thus allowing that single provider to be bound by multiple clients). A follow-up PR is ready for this - #190

This PR introduces OpenFeature eventing spec [1] to Go SDK. The implementation is non-breaking and providers which plan to support eventing can opt-in by implementing EventHandler interface.

Implementation

EventHandler interface contains a single method EventChannel() <- chan Event. OpenFeature core implementation performs a type assertion on the provider for EventHandler and listen to Event channel. It is provider implementation responsibility to emit spec-compliant events (ex:- ProviderReady when initialization is complete OR ProviderError when initialization failed)

The core event handling logic is concentrated on event_executor.go. OpenFeature core implementation maintains a single EventExecutor instance that handles both global (api) level events and client level (scoped) events.

Client and API both add and remove event handlers (callbacks) through their spec client accessors and these get stored at the global EventExecutor

flowchart TD
    A[OpenFeature] -->|Register Global Handler|D
    D[API Singleton] -->  B(EventExecutor)
    C[Client Instance] -->|Register Client Handler|D

Loading

When handling events from providers, all global-level handlers are always invoked. But, the client (scoped) handlers only run if they are associated with the specific provider. This is done by comparing event payload's provider name & registered client name of the handler

sequenceDiagram
    Provider->>+EventExecutor: Emit Event: ProviderReady
    EventExecutor-->>EventExecutor: Run Global Handlers
    EventExecutor-->>EventExecutor: Run Client Handlers - filter with provider name

Loading

Testing

Consider checking event_executor_test.go [2] to validate spec compliance as well as the correctness of the implementation

[1] - https://github.com/open-feature/spec/blob/main/specification/sections/05-events.md#5-events
[2] - https://github.com/open-feature/go-sdk/blob/fe93b46b4afc11533b0530314cc71a823abfe705/pkg/openfeature/event_executor_test.go

[codecov]

Codecov Report

Merging #188 (f98c9bb) into main (501c34b) will increase coverage by 4.05%.
The diff coverage is 90.55%.

@@            Coverage Diff             @@
##             main     #188      +/-   ##
==========================================
+ Coverage   72.97%   77.03%   +4.05%     
==========================================
  Files           8        9       +1     
  Lines         766      997     +231     
==========================================
+ Hits          559      768     +209     
- Misses        187      207      +20     
- Partials       20       22       +2     

Impacted Files	Coverage Δ
pkg/openfeature/provider.go	68.00% <0.00%> (-32.00%)	⬇️
pkg/openfeature/api.go	90.09% <60.00%> (-4.81%)	⬇️
pkg/openfeature/openfeature.go	97.67% <93.33%> (-2.33%)	⬇️
pkg/openfeature/event_executor.go	96.33% <96.33%> (ø)
pkg/openfeature/client.go	70.44% <100.00%> (+0.24%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[toddbaert]

Looks good to me overall, with a few nits (assuming the 1:N issue is fixed elsewhere).

[Kavindu-Dodan]

Looks good to me overall, with a few nits (assuming the 1:N issue is fixed elsewhere).

correct, 1:N support was missing in this implementation and I am actively working on enabling this.