Skip to content
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

Merged
merged 29 commits into from
Oct 30, 2023
Merged

Conversation

chris-hoefgen
Copy link
Contributor

@chris-hoefgen chris-hoefgen commented Oct 20, 2023

  • Add new OpenFeature Provider to the SDK
  • Clean up some of the exception handling

@chris-hoefgen chris-hoefgen marked this pull request as draft October 20, 2023 23:10
@chris-hoefgen chris-hoefgen marked this pull request as ready for review October 24, 2023 21:27
@chris-hoefgen chris-hoefgen requested a review from a team October 25, 2023 16:23
Copy link
Contributor

@rob-odwyer rob-odwyer left a 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.

Copy link

@liran2000 liran2000 left a 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.

OpenFeature.md Outdated Show resolved Hide resolved
@chris-hoefgen chris-hoefgen merged commit 5475ca3 into main Oct 30, 2023
8 checks passed
Comment on lines +89 to +94
return ProviderEvaluation.<Value>builder()
.value(defaultValue)
.reason(Reason.ERROR.toString())
.errorCode(ErrorCode.GENERAL)
.errorMessage(e.getMessage())
.build();

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.

Comment on lines +133 to +138
return ProviderEvaluation.<T>builder()
.value(defaultValue)
.reason(Reason.ERROR.toString())
.errorCode(ErrorCode.GENERAL)
.errorMessage(e.getMessage())
.build();

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines +22 to +29
DevCycleLocalClient devCycleClient = new DevCycleLocalClient(server_sdk_key, options);

for (int i = 0; i < 10; i++) {
if (devCycleClient.isInitialized()) {
break;
}
Thread.sleep(500);
}
Copy link

@toddbaert toddbaert Nov 3, 2023

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.

Copy link

@toddbaert toddbaert left a 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants