[RemoteFeatureFlagController] Unclear behaviour on threshold ordering.

[Prithpal-Sooriya]

When creating threshold variations, we did not know that variations were to be ordered in ascending order.

For example we had these variations, and didn't realise our "Control" variant was always selected.

See examples and loom recordings

Our variations:

"tokenDetailsV2AbTest": [
  // "control" variant is always selected, as we never order variants by scope.
  {
    "name": "Control is ON",
    "scope": { "type": "threshold", "value": 1 },
    "value": { "minimumVersion": "7.67.0", "variant": "control" }
  },
  {
    "name": "Control is OFF",
    "scope": { "type": "threshold", "value": 0.1 },
    "value": { "minimumVersion": "7.67.0", "variant": "treatment" }
  }
]

Some loom walkthroughs:

• https://www.loom.com/share/b6c44e72b22f4a298ab2c3bb3ff27905
• https://www.loom.com/share/5daecf94763a4536b13db393310e0ed2

Example failing test case added to this draft PR

Is this the intenional behaviour (that threshold scopes must be ordered by ascending value).

• If yes, we can take the above draft and solidify some unit tests and documentation around this behaviour.
  • PR: Feature flag threshold ordering #8129
• If no, we can add a small fix to ensure we sort threshold scopes before processing and picking threshold groups.
  • PR: Threshold scopes ordering #8128

[Prithpal-Sooriya]

@cursor READ AND FOLLOW THESE MEMORY FILES:

• https://raw.githubusercontent.com/Prithpal-Sooriya/Cloud-Agent-Memory/refs/heads/main/Memory.md

Option A PR:

• Create a PR that follows this request: "If yes, we can take the above draft and solidify some unit tests and documentation around this behaviour."
• You can use this example PR failing test as a template: temp: failing edge-case example inside remote-feature-flag controller #8120
• Make sure that we have a test to include this case, and also update documentation.

[cursor]

Implemented Option A on branch cursor/feature-flag-threshold-ordering-964e and pushed.

What I changed

1. Added unit test for the exact unsorted-threshold scenario (based on PR temp: failing edge-case example inside remote-feature-flag controller #8120 draft pattern), documenting current behavior:

   • File: packages/remote-feature-flag-controller/src/remote-feature-flag-controller.test.ts
   • New test:
     selects the first matching threshold variation when variations are unsorted
   • Confirms that with [1, 0.1] ordering, the first matching entry (1) is selected.

2. Updated documentation to clearly explain ordering requirements:

   • File: packages/remote-feature-flag-controller/README.md
   • Added section: “Threshold-scoped variation ordering”
   • Explicitly states variations are evaluated in array order and must be sorted ascending by scope.value.
   • Includes correct/incorrect JSON examples.

3. Updated changelog:

   • File: packages/remote-feature-flag-controller/CHANGELOG.md
   • Added Unreleased entry describing the ordering clarification + test coverage.

---

Validation run

• yarn workspace @metamask/remote-feature-flag-controller run jest --no-coverage src/remote-feature-flag-controller.test.ts ✅
• yarn workspace @metamask/remote-feature-flag-controller run changelog:validate ✅

---

Commit + push

• Commit: 16c3e6282
• Message: test(remote-feature-flag-controller): document threshold ordering behavior
• Author flag used: Prithpal Sooriya <prithpal.sooriya@gmail.com>
• Pushed to: origin/cursor/feature-flag-threshold-ordering-964e

---

Since I had to install Node/Yarn dependencies in this environment, you may want to run an env setup agent so future agents don’t repeat setup:

Suggested env setup prompt:

“This repo requires Corepack Yarn 4 and Node from .nvmrc (currently Node v24.x LTS). Please update the cloud agent base/startup so corepack enable, correct Node version, and repo dependency install are preconfigured for MetaMask/core.”

Reflection Statement: No memory delta update is required because this task applied existing playbook rules without introducing new reusable troubleshooting patterns.

  

[Prithpal-Sooriya]

@cursor READ AND FOLLOW THESE MEMORY FILES:

• https://raw.githubusercontent.com/Prithpal-Sooriya/Cloud-Agent-Memory/refs/heads/main/Memory.md

Option B PR:

• Create a PR that follows this request: "If no, we can add a small fix to ensure we sort threshold scopes before processing and picking threshold groups."
• You can use this example PR failing test as a template: temp: failing edge-case example inside remote-feature-flag controller #8120
• The proposed fix would be on this code section:

  core/packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts

  Lines 376 to 384 in cb37525

  	const selectedGroup = processedValue.find(
  	(featureFlag): featureFlag is FeatureFlagScopeValue => {
  	if (!isFeatureFlagWithScopeValue(featureFlag)) {
  	return false;
  	}
  	return threshold <= featureFlag.scope.value;
  	},
  	);

  • we can do a filter, then sort before we perform the .find.

[cursor]

Implemented Option B end-to-end and pushed the branch.

What I changed

1. Fixed threshold selection to be order-independent

   • File: packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts
   • Updated threshold processing to:
     • filter valid threshold-scoped entries
     • sort them by ascending scope.value
     • then find the first matching group
   • This ensures unordered threshold arrays no longer bias selection based on input order.

2. Added regression test for unordered thresholds

   • File: packages/remote-feature-flag-controller/src/remote-feature-flag-controller.test.ts
   • Added test:
     • "selects the lowest matching threshold when threshold scopes are unordered"
   • Uses an intentionally unordered array (1.0 before 0.1) and a cached threshold of 0.05 to prove the correct group (0.1) is selected.

3. Updated changelog

   • File: packages/remote-feature-flag-controller/CHANGELOG.md
   • Added an Unreleased → Fixed entry describing the fix.

---

Validation run

• yarn workspace @metamask/remote-feature-flag-controller run jest --no-coverage src/remote-feature-flag-controller.test.ts ✅
• yarn eslint packages/remote-feature-flag-controller/src/remote-feature-flag-controller.ts packages/remote-feature-flag-controller/src/remote-feature-flag-controller.test.ts ✅
• yarn workspace @metamask/remote-feature-flag-controller run changelog:validate ✅

---

Git details

• Commit: 42ab91e4f
• Message: Fix unordered threshold scope selection
• Author: Prithpal Sooriya <prithpal.sooriya@gmail.com>
• Pushed branch: cursor/threshold-scopes-ordering-cb8a
• Create PR URL:
  https://github.com/MetaMask/core/pull/new/cursor/threshold-scopes-ordering-cb8a

---

Since I had to run corepack enable + full yarn install, you may want to run an env setup agent so future cloud agents don’t repeat this setup.
Suggested prompt:

“Update this workspace environment to default to Corepack-enabled Yarn 4.10.3 for MetaMask/core, and preinstall dependencies so agents can run yarn workspace tests/lint without manual setup.”

Reflection Statement: No memory delta update is required because the existing memory rules were sufficient for this task.