fix: Normalize remote feature flag value wrappers by pedronfigueiredo · Pull Request #8908 · MetaMask/core

pedronfigueiredo · 2026-05-27T13:24:39Z

There is an issue with the current remote feature flag implementation.

As you can see when the feature flags are configured for threshold based config, we define an array of objects that contains name, scope, and value. The problem with this is that there's lots of feature flags that are not defined in this format, and the selectors are unfortunately coupled to this format.

getIsNotificationEnabledByDefaultFeatureFlag inside ui/selectors/metamask-notifications/metamask-notifications.ts expects a .value property for example. But confirmations_pay feature flag, we don't expect such .value property to house the configuration JSON, and instead it's available directly at the root level.

Summary

Normalize processed remote feature flag wrapper objects that include a top-level value field.
Copy object-valued value contents onto the root flag object while preserving the original .value field.
Preserve direct feature flag config objects that do not use wrapper metadata.

Root Cause

Some consumers read feature flag config directly from the flag object, while threshold or version wrapper shapes expose config under .value. This made selectors depend on the rollout format instead of the feature flag config itself.

Impact

Feature flags can move between direct, threshold, and versioned configurations without requiring selectors to switch between direct config access and .value access. Existing consumers that still read .value remain compatible.

Note

Medium Risk
Changes the shape of processed threshold flags for v2 entries, which can affect any consumer expecting the legacy wrapper; legacy behavior is unchanged.

Overview
Threshold-based remote feature flags now normalize the winning segment through normalizeThresholdValue, instead of always emitting { name, value }.

Entries with thresholdVersion: 2 expose the selected config object directly (e.g. { enabled, minimumVersion }), so UI code can read flags the same way as non-threshold configs. Legacy threshold rows without that version still get the name / value wrapper. Optional thresholdName and thresholdVersion were added to FeatureFlagScopeValue, with tests covering direct configs, legacy wrappers, and v2 behavior.

^{Reviewed by Cursor Bugbot for commit 363c9fd. Bugbot is set up for automated code reviews on this repo. Configure here.}

matthewwalsh0 · 2026-05-28T08:12:14Z

+  };
+}
+
+function normalizeFeatureFlagValue(featureFlagValue: Json): Json {


For clarity, should we call this normalizeThresholdValue?

matthewwalsh0 · 2026-05-28T08:13:49Z


-      processedFlags[remoteFeatureFlagName] = processedValue;
+      processedFlags[remoteFeatureFlagName] =
+        normalizeFeatureFlagValue(processedValue);


As we also normalize for versioning, would it be simpler to normalize on line 412 above, so a function specific for getting threshold data?

matthewwalsh0 · 2026-05-28T08:19:31Z

+
+function normalizeFeatureFlagValue(featureFlagValue: Json): Json {
+  return isFeatureFlagValueWrapper(featureFlagValue)
+    ? spreadFeatureFlagValueWrapper(featureFlagValue)


Am I misreading or is this saying if the flag is an object with a value property, then return the value property directly also?

But won't that mean we duplicate the data in every threshold flag?

Could we check (just for the threshold flow) if a thresholdVersion property exists and if set to 2, then we just return value directly? And maybe with a thresholdName property instead of name for clarity?

Yes we do duplicate because although we know in this function what is the shape of the flag defined on launch darkly, we have no way of knowing at this point what is the shape of the data that the selector needs or expects. In other words, we need this change to be backwards compatible.

We have to support three cases:

If a threshold hasn't been defined, then just add the whole flag

If a threshold is defined, and the selectors are currently defined without .value, we want to spread the .value at the root level so no selector change is required (to support our confirmations_pay with thresholds use case)

If a threshold is defined, and the selectors already have .value, we also need to keep the .value prop that the selector expects.

To support 2 and 3 simultaneously we need to duplicate the data.

I am not sure what you mean by the thresholdVersion prop with value 2, I can't see it in the client config api response. Can you clarify?

I was suggesting we make the distinction explicit with a new property such as thresholdVersion: 2 that we put in one of the array entries, so the code knows to only spread the value, rather than including it as it does currently.

Both should solve the problem, but didn't know if we wanted to future-proof and make the RemoteFeatureFlagController state more readable?

matthewwalsh0 · 2026-05-28T13:11:23Z

+      return null;
+    }
+
+    return isFeatureFlagValueWrapper(versionData)


Doesn't the chosen version data get assigned to processedValue and then hit the standard threshold flow so we don't need to touch this?

matthewwalsh0 · 2026-05-28T13:12:35Z

+}
+
+function normalizeThresholdValue(featureFlag: FeatureFlagScopeValue): Json {
+  if (featureFlag.thresholdVersion === THRESHOLD_VALUE_VERSION) {


Minor, if we add future versions, this constant might get confusing. Maybe an enum?

matthewwalsh0 · 2026-05-28T13:13:29Z

+
+function normalizeThresholdValue(featureFlag: FeatureFlagScopeValue): Json {
+  if (featureFlag.thresholdVersion === THRESHOLD_VALUE_VERSION) {
+    return featureFlag.value;


Minor, could still be useful to also include thresholdName property only if an object, for debug in the client?

Not sure how this will impact the new AB testing hooks.

good points let's add that if and when it becomes necessary then

matthewwalsh0 · 2026-05-28T13:15:48Z

+  const name = featureFlag.thresholdName ?? featureFlag.name;
+
+  return {
+    ...(isJsonObject(featureFlag.value) ? featureFlag.value : {}),


If this is the fallback for the existing support, can we just return the same?

{ name: featureFlag.name, value: featureFlag.value }

good point, I forgot to revert this part

matthewwalsh0 · 2026-05-28T13:17:18Z

+  );
+}
+
+function spreadFeatureFlagValueWrapper(


Not needed?

matthewwalsh0 · 2026-05-28T13:17:23Z

+  return typeof value === 'object' && value !== null && !Array.isArray(value);
+}
+
+function isFeatureFlagValueWrapper(


Not needed?

matthewwalsh0 · 2026-05-28T13:17:28Z

  };
 }

+function isJsonObject(value: Json): value is JsonObject {


Not needed?

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 9dc313d. Configure here.}

pedronfigueiredo changed the title ~~[codex] Normalize remote feature flag value wrappers~~ fix: Normalize remote feature flag value wrappers May 27, 2026

pedronfigueiredo marked this pull request as ready for review May 27, 2026 16:37

pedronfigueiredo requested review from a team as code owners May 27, 2026 16:37

pedronfigueiredo temporarily deployed to default-branch May 27, 2026 16:38 — with GitHub Actions Inactive

matthewwalsh0 requested changes May 28, 2026

View reviewed changes

pedronfigueiredo force-pushed the pnf/remote-feature-flag-renormalization branch from 37347e8 to 8576910 Compare May 28, 2026 09:59

pedronfigueiredo requested a review from matthewwalsh0 May 28, 2026 09:59

pedronfigueiredo force-pushed the pnf/remote-feature-flag-renormalization branch from 66f42ad to 0f896ee Compare May 28, 2026 11:31

cursor Bot reviewed May 28, 2026

View reviewed changes

Comment thread packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts Outdated

cursor Bot reviewed May 28, 2026

View reviewed changes

Comment thread packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts

fix: Normalize remote feature flag value wrappers

761c717

pedronfigueiredo force-pushed the pnf/remote-feature-flag-renormalization branch from a525b59 to 761c717 Compare May 28, 2026 13:03

matthewwalsh0 requested changes May 28, 2026

View reviewed changes

pedronfigueiredo added 3 commits May 28, 2026 14:28

Remove unsupported version flag wrapper normalization

4b6e1cc

Use enum for threshold versions

b0a1f11

Preserve legacy threshold wrapper fallback

9dc313d

cursor Bot reviewed May 28, 2026

View reviewed changes

Comment thread packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts Outdated

Restore direct version data return

363c9fd

Uh oh!

Conversation

pedronfigueiredo commented May 27, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Root Cause

Impact

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!

Uh oh!

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!

pedronfigueiredo May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pedronfigueiredo commented May 27, 2026 •

edited by cursor Bot

Loading

pedronfigueiredo May 28, 2026 •

edited

Loading