Threshold scopes ordering

[Prithpal-Sooriya]

Explanation

• What is the current state of things and why does it need to change?
  The remote-feature-flag-controller's logic for selecting a threshold group could be influenced by the order of thresholdScope entries in the feature flag configuration. If the thresholdScope array was not sorted, the .find operation might pick a suboptimal or incorrect threshold group, leading to inconsistent feature flag evaluation.
• What is the solution your changes offer and how does it work?
  This PR introduces a fix to ensure that thresholdScope entries are explicitly sorted by their scope.value in ascending order before the .find operation is performed. This guarantees that the lowest matching threshold is always selected, making the threshold group selection deterministic and independent of the input array's order.
• Are there any changes whose purpose might not obvious to those unfamiliar with the domain?
  The sorting step ensures that even if the feature flag configuration provides threshold scopes in an arbitrary order (e.g., 1.0 before 0.1), the controller will consistently evaluate them as if they were ordered, picking the most appropriate (lowest matching) threshold.

References

• [RemoteFeatureFlagController] Unclear behaviour on threshold ordering. #8122

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

  

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}