-
Notifications
You must be signed in to change notification settings - Fork 0
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: Add OpenFeature provider #111
Conversation
chris-hoefgen
commented
Oct 20, 2023
•
edited
Loading
edited
- Add new OpenFeature Provider to the SDK
- Clean up some of the exception handling
11410e2
to
d74590c
Compare
src/main/java/com/devcycle/sdk/server/cloud/api/DevCycleCloudClient.java
Outdated
Show resolved
Hide resolved
src/main/java/com/devcycle/sdk/server/openfeature/DevCycleUserFactory.java
Outdated
Show resolved
Hide resolved
src/main/java/com/devcycle/sdk/server/openfeature/DevCycleProvider.java
Outdated
Show resolved
Hide resolved
src/main/java/com/devcycle/sdk/server/openfeature/DevCycleUserFactory.java
Outdated
Show resolved
Hide resolved
src/main/java/com/devcycle/sdk/server/common/model/DevCycleUser.java
Outdated
Show resolved
Hide resolved
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.
Looks solid - just a few questions.
At a high level I'm unsure about whether we want to throw some of the exceptions vs. mimic the DevCycle SDK's strategy of minimizing errors in favor of returning defaults.
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.
LGTM from OpenFeature perspective.
Left comments on context wrapping and PROVIDER_NAME.
src/main/java/com/devcycle/sdk/server/openfeature/DevCycleProvider.java
Outdated
Show resolved
Hide resolved
…n unit tests with the local bucketing client
…cal in the provider
…ust ignore the bad value
b31d6c9
to
4e21dc9
Compare
return ProviderEvaluation.<Value>builder() | ||
.value(defaultValue) | ||
.reason(Reason.ERROR.toString()) | ||
.errorCode(ErrorCode.GENERAL) | ||
.errorMessage(e.getMessage()) | ||
.build(); |
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.
I would suggest changing this to throw an error. The SDK handles all the defaulting in that case. This is important because in the case of the Java SDK, the error hooks/telemetry only run if an error is thrown during evaluation.
I realize this is confusing because we allow for the errorCode
and errorMessage
to be set, which gives the impression this is a valid way to communicate errors up the call stack. We're considering changing this to make things clearer.
return ProviderEvaluation.<T>builder() | ||
.value(defaultValue) | ||
.reason(Reason.ERROR.toString()) | ||
.errorCode(ErrorCode.GENERAL) | ||
.errorMessage(e.getMessage()) | ||
.build(); |
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.
DevCycleLocalClient devCycleClient = new DevCycleLocalClient(server_sdk_key, options); | ||
|
||
for (int i = 0; i < 10; i++) { | ||
if (devCycleClient.isInitialized()) { | ||
break; | ||
} | ||
Thread.sleep(500); | ||
} |
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.
It depends on how DevCycle users already use the product, but if you want to avoid something like this in OpenFeature use-cases, you could implement the getState method, and return NOT_READY
, then do something like this in the initialize
method of the provider, and setting READY and returning when you have initialized.
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.
Again late to the party, but left some suggestions.