feat!: evaluate feature flags through the v4 endpoints - #53
Open
lourens-octopus wants to merge 2 commits into
Open
feat!: evaluate feature flags through the v4 endpoints#53lourens-octopus wants to merge 2 commits into
lourens-octopus wants to merge 2 commits into
Conversation
lourens-octopus
force-pushed
the
lourens/bmbb-753
branch
from
August 11, 2026 20:50
00cc80b to
891aee6
Compare
The switch to v4 needs the evaluator, which lives in the provider package, to call ServerSideEvaluation.evaluate(). Java package access is not hierarchical, so keeping the v4 types in a sub-package would mean making them public — permanently, since nothing later removes the split. With v4 becoming the only contract, the sub-package has served its purpose: it kept an unreleased contract out of the way while v3 was live. Everything stays package-private in one package, and the public API is unchanged. A pure move: no behaviour changes, and the two test-only shims that only existed to cross the package boundary are gone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Switches the provider from the v3 toggle endpoints to the v4 feature-flag endpoints, and from v3's segment and rollout matching to the rules-based evaluation added earlier. - GET api/feature-flags/check/v4/ and api/feature-flags/evaluations/v4/ - EvaluationResponse replaces FeatureToggles - evaluate(slug, context) resolves a ServerSideEvaluation, so the value and reason come from the server or from the client-side rules it deferred, and a malformed response reports the problem it found - an unrecognised slug throws FlagNotFoundError with the message the other provider libraries use - specification fixtures move to the v4 evaluations set v3's types remain, unused, for BMBB-780. BREAKING CHANGE: the provider now calls the v4 feature-flag endpoints and evaluates rules-based flags. A server that only serves the v3 toggle endpoints is no longer supported. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
lourens-octopus
force-pushed
the
lourens/bmbb-753
branch
from
August 11, 2026 21:01
891aee6 to
27aea2c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves BMBB-753 and BMBB-749. Java counterpart of openfeature-provider-dotnet#96, brought up to date with .NET's current code.
Stacked on #51 — review that first; this branch targets it.
What
The provider now evaluates through the v4 feature-flag endpoints, using the rules-based evaluation from #51 instead of v3's segment and rollout matching.
api/feature-flags/check/v4/andapi/feature-flags/evaluations/v4/EvaluationResponsereplacesFeatureToggles;getServerSideEvaluations()replacesgetFeatureToggleEvaluationManifest()evaluate(slug, context)dropsdefaultValueand resolves aServerSideEvaluation, so value and reason come from the server or from the rules it deferred, and a malformed response reports the problem it foundFlagNotFoundErrorwith the message the other providers use, warned once per slug rather than on every evaluationef84509→67890d8BREAKING CHANGE:is on the commit so release-please cuts the major; cutting the release is BMBB-772.Two commits
refactor: flatten the v4 package into the provider package— a pure move, green on its own.The switch needs the evaluator, in the provider package, to call
ServerSideEvaluation.evaluate(). Package access is not hierarchical, so av4sub-package would mean making that type andEvaluationResponsepublic — permanently, sinceOctopusProviderkeeps its fully-qualified name and so the parent→v4call outlives BMBB-780. With v4 now the only contract, the sub-package has served its purpose. Everything stays package-private, the public API is unchanged, and #51's duplicated rollout hash collapses back to one implementation.feat!: evaluate feature flags through the v4 endpoints— the switch.Scope
BMBB-749 is here because it cannot be split off: the specification bump replaces its fixtures (10 added, 4 deleted, 2 renamed) and a submodule has one pointer, so bumping first leaves v4 fixtures against a v3 provider — 80 failures, which I hit while separating the commits — and switching first leaves v4 code against deleted fixtures. .NET adopted the fixtures inside its own switch PR for the same reason.
Left to the tickets that own them, mirroring .NET's #96 → #99:
FeatureToggles,FeatureToggleEvaluationandSegmentremain, unused, markedTODO(BMBB-780). Their evaluation logic is gone, since replacing it is the switch, soOctopusContextTestsdrops from 291 lines to 108.OctopusContext→FeatureFlagEvaluator, and so on). BMBB-715 looks like a duplicate of it.Tests
452 pass, 0 failures, including all 83 specification tests (up from 41 — the v4 fixture set is larger). New
OctopusClientTestscases pin both endpoint paths against WireMock, as .NET's do. Public API confirmed unchanged viajavap.🤖 Generated with Claude Code