feat: Openfeature Provider Update #280
Conversation
- Rework flattened provider handler
| for { | ||
| time.Sleep(time.Millisecond * 100) | ||
| event := <-inithandler | ||
| if event.EventType == api.ClientEventType_Initialized { |
There was a problem hiding this comment.
would it make more sense to use the initialized method on the provider?
There was a problem hiding this comment.
or actually this: https://openfeature.dev/docs/reference/technologies/server/go#eventing
There was a problem hiding this comment.
No - because we need a guaranteed return status and this event is the guarantee - I was fighting race conditions with the initialized method
There was a problem hiding this comment.
Does the OF one not guarantee to return?
There was a problem hiding this comment.
nope - it can return an error
There was a problem hiding this comment.
yea so can we catch the error?
There was a problem hiding this comment.
That won't do what we want here - which is to guarantee the sdk has initialized before doing any openfeature operations.
The provider just returns whether or not there's handling done in specifically the provider for init - so we need to wait for the client to init itself. The status function in the provider has no context to the client to know whether or not it's been initialized - just closed - https://github.com/DevCycleHQ/go-server-sdk/pull/280/files#diff-68983a7a553e04797e31fac83289f03d99f68a233e874a2d0d9ea56efb2f36d7R63-R68
We have this because otherwise the calls will always fail and throw an exception of "provider not initialized" when that's not true and the provider can handle the request.
We specifically do this because the sdk can handle defaults before init is complete.
The SDK is the only true source - hence waiting on the initialization event from the SDK to be emitted.
There was a problem hiding this comment.
yea all I'm getting at here, is that we really should be trying to have these examples use the OpenFeature "native" way as much as possible, as that's what our customers will expect when they come to us for OpenFeature SDKs.
There was a problem hiding this comment.
Yep - agreed - though our initialization handling across all our SDKs is tricky and handled differently per language.
No description provided.