Skip to content

feat!: go sdk v2#460

Open
erka wants to merge 5 commits intomainfrom
next
Open

feat!: go sdk v2#460
erka wants to merge 5 commits intomainfrom
next

Conversation

@erka
Copy link
Member

@erka erka commented Jan 13, 2026

This PR

  • OpenFeature Go SDK v2

Notes

  • The starting point for discussions.
  • Play with it
go get go.openfeature.dev/openfeature/v2@next
  • Please read MIGRATION_GUIDE.md

@codecov
Copy link

codecov bot commented Jan 13, 2026

Codecov Report

❌ Patch coverage is 90.13761% with 43 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.17%. Comparing base (6085165) to head (c432dbb).

Files with missing lines Patch % Lines
providers/multi/multi_provider.go 69.38% 14 Missing and 1 partial ⚠️
client.go 93.45% 6 Missing and 1 partial ⚠️
providers/multi/run_mode.go 83.33% 6 Missing ⚠️
event_executor.go 86.20% 3 Missing and 1 partial ⚠️
provider.go 0.00% 3 Missing ⚠️
providers/multi/isolation.go 88.00% 3 Missing ⚠️
providers/testing/test_provider.go 91.30% 1 Missing and 1 partial ⚠️
openfeature_api.go 95.23% 0 Missing and 1 partial ⚠️
providers/inmemory/inmemory_provider.go 87.50% 1 Missing ⚠️
providers/multi/comparison_strategy.go 97.67% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #460      +/-   ##
==========================================
+ Coverage   83.23%   86.17%   +2.94%     
==========================================
  Files          27       21       -6     
  Lines        2111     1939     -172     
==========================================
- Hits         1757     1671      -86     
+ Misses        305      231      -74     
+ Partials       49       37      -12     
Flag Coverage Δ
e2e 86.17% <90.13%> (+2.94%) ⬆️
unit 86.17% <90.13%> (+2.94%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @erka, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request upgrades the OpenFeature Go SDK to version 2, introducing a modernized API that emphasizes context propagation, improved type safety through generics, and clearer error handling. The changes streamline the developer experience by simplifying evaluation calls and providing a structured migration path for existing users.

Highlights

  • Major Version Update (v2): This pull request introduces version 2 of the OpenFeature Go SDK, featuring significant API changes and improvements.
  • Context-Aware API Design: The SDK has been refactored to be more context-aware, with most provider and client methods now requiring a context.Context parameter for better control over timeouts and cancellations.
  • Simplified Evaluation Methods: Evaluation methods that previously returned (value, error) (e.g., BooleanValue) have been removed. Users should now use non-error variants (e.g., Boolean) which return a default value on error, or *ValueDetails methods for detailed evaluation results.
  • Enhanced Type Safety and Generics: Internal interfaces and types have been updated for improved type safety and consistency, leveraging Go generics for evaluation details and resolution details.
  • Migration Guide and Tooling: A comprehensive MIGRATION_GUIDE.md has been added, detailing all breaking changes and providing step-by-step instructions, including an optional gopatch file for automated migration of common patterns.
  • Decoupled Logging: Deprecated logging methods (SetLogger, Client.WithLogger) have been removed, promoting the use of the LoggingHook for integrating with preferred logging solutions.
  • Package Restructuring: Internal provider implementations like memprovider and multi have been moved under a new providers directory (providers/inmemory, providers/multi) for better organization.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces a major version bump to v2 of the OpenFeature Go SDK. It includes significant and well-documented breaking changes that modernize the API, improve type safety with generics, and make the provider lifecycle fully context-aware. The changes are extensive, involving refactoring of core components like the client and provider interfaces, restructuring packages, and updating documentation. The addition of a detailed migration guide is particularly helpful. Overall, this is a substantial and well-executed upgrade. I've identified a critical compile error and a couple of minor issues related to a typo and documentation consistency that should be addressed.

@erka erka marked this pull request as ready for review January 13, 2026 00:19
@erka erka requested review from a team as code owners January 13, 2026 00:19
@sahidvelji
Copy link
Contributor

sahidvelji commented Jan 23, 2026

@erka Given #464, do you think it makes sense to switch from int64 to int in this PR, for v2?

cc @leoromanovsky

@erka
Copy link
Member Author

erka commented Jan 23, 2026

That’s a difficult question. From what I can see in the OpenFeature spec, only number is defined, and Integer and Float aren’t specified. Maybe we could change it to follow the spec with such interface.

type Number interface {
	~int | ~int8 | ~int16 | ~int32 | ~int64 |
		~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64  |
		~float32 | ~float64 
}

But it may not be very developer-friendly to use in code and migration might be tricky. @sahidvelji

erka added 3 commits January 23, 2026 21:05
Signed-off-by: Roman Dmytrenko <rdmytrenko@gmail.com>
Signed-off-by: Roman Dmytrenko <rdmytrenko@gmail.com>
Signed-off-by: Roman Dmytrenko <rdmytrenko@gmail.com>
Replace default case with direct channel send to prevent potential
goroutine leaks when context is cancelled.

Signed-off-by: Roman Dmytrenko <rdmytrenko@gmail.com>
@sahidvelji
Copy link
Contributor

Agreed. I think either int or int64 make sense, but I don't have a strong opinion either way.

Signed-off-by: Roman Dmytrenko <rdmytrenko@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants