[pull] main from MetaMask:main - #793
Merged
Merged
Conversation
## Explanation Release bridge-status-controller <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > <sup>[Cursor Bugbot](https://cursor.com/bugbot) is generating a summary for commit b782d14. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
…MetricsFlags with canonical ID default (#9325) ## Summary - Add required `getCanonicalProfileId` constructor callback and `metaMetricsFlags` map for threshold flag segmentation. - Threshold flags use canonical profile ID by default; flags whose names are present in `metaMetricsFlags` use MetaMetrics ID instead. - Generalize threshold calculation to hash the selected segmentation ID while preserving the existing deterministic bucketing behavior. - Pass the new segmentation options through `@metamask/wallet` remote feature flag controller initialization. ## Segmentation Behavior | Flag configuration | Identifier used | Constructor callback | | --- | --- | --- | | Flag name absent from `metaMetricsFlags` | Canonical profile ID | `getCanonicalProfileId()` | | Flag name present in `metaMetricsFlags` | MetaMetrics ID | `getMetaMetricsId()` | If the selected identifier is empty, threshold arrays are preserved as-is and not processed. Example threshold config using canonical segmentation by default: ```json { "myCanonicalFlag": [ { "name": "groupA", "scope": { "type": "threshold", "value": 0.5 }, "value": "valueA" }, { "name": "groupB", "scope": { "type": "threshold", "value": 1.0 }, "value": "valueB" } ] } ``` Example controller setup for a flag that should keep MetaMetrics segmentation: ```ts new RemoteFeatureFlagController({ // ... getMetaMetricsId, getCanonicalProfileId, metaMetricsFlags: { legacyMetaMetricsFlag: true, }, }); ``` ## Migration Consumers must pass `getCanonicalProfileId` for threshold flags that should use canonical profile segmentation, which is now the default for flags absent from `metaMetricsFlags`. Existing threshold flags that must keep MetaMetrics-based bucketing should be listed in `metaMetricsFlags` and continue to provide `getMetaMetricsId`. ## Test plan - [x] `yarn workspace @metamask/remote-feature-flag-controller run jest --no-coverage src/utils/user-segmentation-utils.test.ts src/remote-feature-flag-controller.test.ts` - [x] Threshold flags absent from `metaMetricsFlags` use `getCanonicalProfileId` for segmentation - [x] Threshold flags present in `metaMetricsFlags` use `getMetaMetricsId` for segmentation - [x] Threshold arrays are preserved when the selected identifier is empty - [x] Threshold cache entries use the selected segmentation ID and stale entries are cleaned up when flags are removed from the server response ## Related - Documentation: [MetaMask/contributor-docs#176](MetaMask/contributor-docs#176) - Ticket - https://consensyssoftware.atlassian.net/browse/MCWP-662 <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Breaking constructor and experiment-assignment change: existing threshold flags will re-bucket unless listed in `metaMetricsFlags`. Not auth or payment logic, but it can change live A/B group membership. > > **Overview** > **Breaking:** threshold flags now bucket by **canonical profile ID** by default instead of MetaMetrics ID. `RemoteFeatureFlagController` requires `getCanonicalProfileId`; flags listed in optional `metaMetricsFlags` still use `getMetaMetricsId`. > > Hash-based assignment hashes the chosen segmentation ID. If that ID is empty, the threshold array is left unprocessed. Explicit MetaMetrics ID targeting is unchanged. Threshold cache keys and stale-entry cleanup cover both identifiers. > > `@metamask/wallet` forwards the new options (optional; empty-string default for canonical ID). Consumers that need the old MetaMetrics bucketing must list those flag names in `metaMetricsFlags`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 09b141f. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Cal-L <cal.leung@consensys.net> Co-authored-by: Cal Leung <cleun007@gmail.com> Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
## Explanation Release of `@metamask/client-utils` covering the shared mobile activity types from [#9916](#9916). ## References * [#9916](#9916) ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them
## Explanation Adds optional size weighting to Scale orders with `OrderParams.scaleSkew`. - Rung weights ramp linearly from `1` at `scaleMinPrice` to `scaleSkew` at `scaleMaxPrice` for both buys and sells. Values above `1` put more size near the maximum price; values below `1` put more near the minimum. - Omitting `scaleSkew`, or setting it to `1`, preserves the existing even split exactly. - `splitScaleSizes` accepts the same optional skew so client previews and submitted orders use one allocation algorithm. It allocates whole size-grid units with deterministic largest-remainder rounding, and the rung sizes always sum to the requested total. - Non-finite and non-positive values are rejected before signing with the existing `ORDER_SCALE_RANGE_INVALID` code. Reusing this code keeps the exported `PerpsErrorCode` union backward-compatible. - A skew that creates a zero-size or below-minimum rung is rejected before the batch reaches the exchange. The new fields are optional, so existing Scale orders and all other order types are unchanged. ## Validation - Full `@metamask/perps-controller` test suite passes. - Targeted Scale/strategy suites: 3 suites, 212 tests passed. - `mm-harness` recipe: 6/6 nodes passed, covering calculation, validation, provider submission, and public exports without a setup shim. - Changed-file ESLint and Prettier checks pass. - Changelog validation passes. The installed harness `metamask.perps.place_order` action does not yet expose Scale parameters, so the recipe provides deterministic provider-level integration proof rather than a live signed testnet placement. ## References - [TAT-3817](https://consensyssoftware.atlassian.net/browse/TAT-3817) - Unblocks TAT-3812 Mobile Scale-order UI work. ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them [TAT-3817]: https://consensyssoftware.atlassian.net/browse/TAT-3817?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes how scale order sizes are allocated before they are signed and submitted. The even-split path is preserved, but incorrect skew math would place a different ladder than the caller previewed. > > **Overview** > Scale orders can now weight size along the price ladder via optional `OrderParams.scaleSkew`, instead of always splitting evenly. > > Weights ramp linearly from 1 at `scaleMinPrice` to `scaleSkew` at `scaleMaxPrice` for both buys and sells. Omitted or `1` keeps the existing even split (leftover on the first rung). Skewed allocation floors each rung in size-grid units and gives leftovers to the largest discarded fractions (ties by index). `splitScaleSizes` is the single source of truth so client previews match placement. > > Invalid skews (`<= 0` or non-finite) and skew on non-`scale` types are rejected before signing (`ORDER_SCALE_RANGE_INVALID` / `ORDER_STRATEGY_PARAMS_NOT_SUPPORTED`). A skew that zeros a rung or drops a rung under the venue minimum is refused with the existing size/notional errors. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 14f5cd0. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## Explanation `AccountsApiDataSource` polls for balances every 30s, but the underlying `ApiPlatformClient` caches responses for 60s (`STALE_TIMES.BALANCES`). Since the poll didn't pass `forceUpdate`, every other tick was served the cached response instead of hitting the network — balances only actually refreshed every ~60s. This passes `forceUpdate: true` on the poll's fetch call so it always bypasses the cache, same as other call sites (unlock, account switch, tx confirmation) already do. Kept the fix scoped to just the poll instead of removing caching everywhere, since #9591 added `forceUpdate` specifically to avoid bursts of duplicate calls when multiple triggers fire close together, and the unmerged #9867 ran into that regression by disabling the cache globally. ## References * Related to #9591 * Related to (closed) #9867 ## Checklist - [x] 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 - [x] I've communicated my changes to consumers by [updating changelogs for packages I've changed](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Narrow cache-bypass on the 30s poll path only; does not change auth or other fetch sites. Slightly more Accounts API traffic on that interval, which is the intended behavior. > > **Overview** > Fixes `AccountsApiDataSource` polling serving stale balances on roughly every other tick. The 30s poll used `fetch()` without `forceUpdate`, so the 60s TanStack balances cache (`STALE_TIMES.BALANCES`) won. > > Recurring `pollFn` now passes `forceUpdate: true` so each tick hits the network (`staleTime: 0, gcTime: 0`), matching other authoritative refreshes. Bypass is scoped to the poll only so nearby unlock/switch/tx triggers still share the cache. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit d162463. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
) ## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> Adding `@metamask/config-registry-controller` to the `wallet` package. ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> * Fixes https://consensyssoftware.atlassian.net/browse/WPN-1894 ## 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Breaking constructor API plus new remote config fetch on wallet startup. Duplicate messenger registration can fail existing consumers that already wire these controllers. > > **Overview** > **BREAKING:** Default wallet init now constructs `ConfigRegistryApiService` and `ConfigRegistryController`, so remote config registry is part of the core wallet graph. > > `instanceOptions.configRegistryApiService` is **required** (`env`, optional `fetch` / `policyOptions`). `configRegistryController` is optional (`pollingInterval`, `fallbackConfig`). The controller messenger delegates keyring, remote feature flags, and `ConfigRegistryApiService:fetchConfig`. > > Consumers that already register these on a custom root messenger must drop their own wiring or registrations will collide. `wallet-cli` passes `ConfigRegistryApiEnv.PRD`. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 4777e53. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
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 freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )