feat: Use new evaluations endpoint by liamhughes · Pull Request #48 · OctopusDeploy/openfeature-provider-ts-web

liamhughes · 2026-04-07T05:34:09Z

Background

The client percentage rollout feature requires ClientRolloutPercentage and EvaluationKey to be included in evaluation responses.

We were unable to add these fields to the existing GET /featuretoggles/v3 evaluations endpoint because the Java OpenFeature provider was previously using Jackson with strict deserialisation. See OctopusDeploy/openfeature-provider-java#5.

This PR updates this provider to use the new endpoint, which has the following changes compared to the old endpoint:

The name field was removed
evaluationKey and clientRolloutPercentage were added, though are only returned if isEnabled evaluated to true in the feature toggles service
segments are also only returned if isEnabled evaluated to true

Resolves DEVEX-137.

Changes

Update URI called by provider and in test WireMock server
Updates to V1FeatureToggleEvaluation interface
- Removed name property
- Added optional evaluationKey and clientRolloutPercentage properties
- Updated segments to be optional
Updates to OctopusFeatureContext class
- Type changes from V1FeatureToggleEvaluation
- Added missingRequiredPropertiesForClientSideEvaluation check
Updated the localStorage backed caching so that old caches will not be used

Notes for review

The new fields are not actually being used yet, but will be in the next PR.
This PR is based on the Java equivalent: Use new evaluations endpoint openfeature-provider-java#7

Testing

Smoke test against a locally running instance of OctoToggle was successful.
All existing tests are passing, albeit with some change in test data.
The majority of specification tests at this commit pass, except those relying on the client rollout functionality. As such, I have disabled the specification tests because there isn't a commit in OctopusDeploy/openfeature-provider-specification that uses the new endpoint response shape that doesn't also expect the client percentage rollout feature to be implemented. This will be implemented and fully tested in the next PR, prior to the next release of this library

Copilot

Pull request overview

Updates the TypeScript OpenFeature provider to call the new Octopus “evaluations” endpoint and aligns the client-side evaluation model with the new response shape (removing name, adding rollout-related fields, and making segments optional).

Changes:

Switch provider/test server calls from /api/featuretoggles/v3/ to /api/toggles/evaluations/v3/.
Update V1FeatureToggleEvaluation to match the new endpoint (remove name, add optional evaluationKey/clientRolloutPercentage, make segments optional).
Add client-side validation for required evaluation fields and adjust segment evaluation logic; disable specification fixture tests for now.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/specificationTests/server.ts	Updates mocked server route to the new evaluations endpoint.
src/specificationTests/fixtureEvaluationTests.test.ts	Skips specification fixture tests pending rollout hashing support.
src/octopusFeatureProvider.test.ts	Updates test evaluation objects to include new fields.
src/octopusFeatureContext.ts	Updates evaluation interface/logic and adds required-field validation for enabled toggles.
src/octopusFeatureContext.test.ts	Updates/extends tests for new evaluation shape and missing-field behavior.
src/octopusFeatureClient.ts	Switches client request URL to the new evaluations endpoint.
src/octopusFeatureClient.test.ts	Updates URL assertion to match the new endpoint.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-07T05:42:20Z

+        if (missingRequiredPropertiesForClientSideEvaluation(evaluation)) {
+            return {
+                value: defaultValue,
+                errorCode: ErrorCode.PARSE_ERROR,
+                errorMessage: `Feature toggle ${slug} is missing necessary information for client-side evaluation.`,
+            };
+        }


The new missingRequiredFieldsForClientEvaluation PARSE_ERROR path will break fallback-to-cache behavior for users upgrading from the previous response shape: cached evaluations (schemaVersion "v1") won’t have evaluationKey/clientRolloutPercentage, so enabled flags will now resolve to defaultValue+PARSE_ERROR whenever the network fetch fails. Consider bumping the cache schema/localStorage key to invalidate older cached manifests, or relaxing this check until client-side rollout logic actually depends on these fields (e.g., only require them when performing rollout hashing).

Huh. The use of local storage could indeed be the source of bugs in the future... I'll find a fix and make a note to discuss this further.

Copilot · 2026-04-07T05:42:21Z

+// Skipped: rollout percentage evaluation (hashing) not yet implemented.
+// Re-enable when the follow-up PR adds that logic.
+test.skip.each(testCases)("$testCase.description", async ({ testResponse, testCase }) => {


test.skip.each(...) still executes the module-level loadTestCases() (and fs.readdirSync) when Jest loads this file, so skipping won’t prevent failures if the specification/Fixtures submodule/directory isn’t present. If the intent is to disable these spec tests temporarily, consider guarding fixture loading with an existence check and conditionally skipping the suite, or making fixture loading lazy so it doesn’t run when skipped.

This is fine. It's only until the next PR.

liamhughes · 2026-04-07T06:03:04Z

-            possibleV1CacheEntry.contents !== undefined &&
-            possibleV1CacheEntry.contents.evaluations !== undefined &&
-            possibleV1CacheEntry.contents.contentHash !== undefined
+            possibleV2CacheEntry.schemaVersion === "v2" &&


This will ensure that previously cached entries won't be used with the new logic.

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

src/octopusFeatureClient.ts:91

axios rejects non-2xx responses by default, so a 404 from this endpoint will throw and never reach the if (response.status == 404) branch. That prevents getEvaluationContext() from falling back to cached/empty toggles as intended. Consider adding validateStatus to allow 404 responses through, or wrapping the request in a try/catch and returning undefined when error.response?.status === 404 (and optionally for other expected failure modes).

        const response = await this.axiosInstance.request<V2FeatureToggleEvaluation[]>(config);

        if (response.status == 404) {
            this.logger.warn(`Failed to retrieve feature toggles for client identifier ${this.clientIdentifier} from ${this.serverUri}`);
            return undefined;

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-04-07T06:11:45Z

            config.headers!["X-Release-Version"] = this.releaseVersionOverride;
        }

-        const response = await this.axiosInstance.request<V1FeatureToggleEvaluation[]>(config);
+        const response = await this.axiosInstance.request<V2FeatureToggleEvaluation[]>(config);

        if (response.status == 404) {
            this.logger.warn(`Failed to retrieve feature toggles for client identifier ${this.clientIdentifier} from ${this.serverUri}`);


Within getFeatureManifest(), header parsing currently relies on response.headers.get("ContentHash") (with a // @ts-ignore). That isn’t safe across Axios adapters/versions because response.headers can be a plain object (no .get) and header names are often normalized to lowercase. Consider reading the header in a way that supports both AxiosHeaders and plain objects (case-insensitive), and remove the ts-ignore once types align.

I've made a note of this for discussion/ticketing.

Copilot · 2026-04-07T06:11:45Z

+    if (!evaluation.isEnabled) {
+        return false;
+    }
+    return evaluation.evaluationKey == null || evaluation.segments == null || evaluation.clientRolloutPercentage == null;


missingRequiredPropertiesForClientSideEvaluation requires segments/evaluationKey/clientRolloutPercentage for enabled toggles, but V2FeatureToggleEvaluation marks all three as optional and the current segment evaluation logic can already treat missing segments as “no segments”. This can cause enabled flags to return PARSE_ERROR + defaultValue for responses where the service omits these fields (e.g., enabled toggle with no segments). Consider either (a) modeling enabled vs disabled evaluations as a discriminated union (enabled => fields required), or (b) relaxing the check to only require fields when they’re actually needed (e.g. when rollout hashing is implemented) and treating segments undefined as an empty list.

Suggested change

return evaluation.evaluationKey == null || evaluation.segments == null || evaluation.clientRolloutPercentage == null;

// The current client-side evaluation only uses `isEnabled` and, optionally,

// `segments`. Missing `segments` is already treated as "no segments" by

// `evaluateSegments`, and rollout metadata is not yet used here.

return false;

I already considered a discriminated union, but that still wouldn't protect against the API returning unexpected values (though we could think about implementing a schema check like zod).

I think Copilot is probably picking up the half-way nature of this PR here. We can tidy in the next PR.

caitlynstocker · 2026-04-08T05:10:17Z

+export interface V2FeatureToggles {
+    evaluations: V2FeatureToggleEvaluation[];
    contentHash: string;
 }


Maybe a silly question but what's the reason for renaming everything to V2?

When I realised I had to update the cache entry, I updated these as well. I have gone with the assumption that the version number related to the shape of the objects rather than the API.

Makes sense ☺️ What would happen if we didn't update the cache entry?

Existing users of the consuming application may use evaluations without the new fields leading to incorrect client-side evaluations.

To be honest, I'm actually not sure how much value the cache is providing and I have a note to discuss it when Dylan gets back.

caitlynstocker

Looks in line with the .NET and Java versions 😊

liamhughes added 4 commits April 7, 2026 14:36

Update endpoint URI

fcb9522

Update, but disable, specification tests

7e3f09c

Update type and add missingRequiredFieldsForClientEvaluation check

0f9222f

Update tests

95dc84a

liamhughes requested a review from Copilot April 7, 2026 05:37

Self review

d10194d

Copilot started reviewing on behalf of liamhughes April 7, 2026 05:38 View session

Copilot AI reviewed Apr 7, 2026

View reviewed changes

OctopusDeploy deleted a comment from Copilot AI Apr 7, 2026

Update to v2 models and cache entry

9aaa776

liamhughes commented Apr 7, 2026

View reviewed changes

liamhughes requested a review from Copilot April 7, 2026 06:06

Copilot started reviewing on behalf of liamhughes April 7, 2026 06:07 View session

Copilot AI reviewed Apr 7, 2026

View reviewed changes

caitlynstocker reviewed Apr 8, 2026

View reviewed changes

caitlynstocker approved these changes Apr 8, 2026

View reviewed changes

liamhughes merged commit 48d8bf5 into main Apr 8, 2026
11 checks passed

liamhughes deleted the liamhughes/devex-137-use-new-evaluations-endpoint branch April 8, 2026 07:54

This was referenced Apr 1, 2026

chore(main): release 3.0.0 #38

Closed

chore(main): release 3.0.0 #50

Closed

team-github-bot mentioned this pull request Apr 9, 2026

chore(main): release 3.0.0 #52

Merged

-    return evaluation.evaluationKey == null || evaluation.segments == null || evaluation.clientRolloutPercentage == null;
+    // The current client-side evaluation only uses `isEnabled` and, optionally,
+    // `segments`. Missing `segments` is already treated as "no segments" by
+    // `evaluateSegments`, and rollout metadata is not yet used here.
+    return false;

Conversation

liamhughes commented Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Background

Changes

Notes for review

Testing

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Apr 7, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

caitlynstocker left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

liamhughes commented Apr 7, 2026 •

edited

Loading