feat: improve chomp upgrade process - #9387
Merged
Merged
Conversation
Jwhiles
force-pushed
the
john-chomp-improvements
branch
from
July 14, 2026 13:39
ffc51f5 to
cba10e0
Compare
Jwhiles
marked this pull request as ready for review
July 14, 2026 13:54
Matt561
approved these changes
Jul 14, 2026
Jwhiles
added a commit
that referenced
this pull request
Jul 16, 2026
- Mark the state-shape change as BREAKING in the changelog; the release is already major via #9387. - Exclude upgradedAccounts from state logs (address-keyed enrollment data, matching precedent in other address-keyed controllers). - Validate that maxAttempts is an integer >= 1 so NaN cannot cause unbounded retries. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Jwhiles
added a commit
that referenced
this pull request
Jul 20, 2026
- Mark the state-shape change as BREAKING in the changelog; the release is already major via #9387. - Exclude upgradedAccounts from state logs (address-keyed enrollment data, matching precedent in other address-keyed controllers). - Validate that maxAttempts is an integer >= 1 so NaN cannot cause unbounded retries. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
pull Bot
pushed a commit
to dmrazzy/core
that referenced
this pull request
Jul 22, 2026
## @metamask/money-account-api-data-service ## [0.3.0] ### Added - Add optional `trace` callback to `MoneyAccountApiDataService` constructor for network request tracing ([MetaMask#9451](MetaMask#9451)) - All HTTP calls (`fetchPositions`, `fetchInterest`, `fetchHistory`, `fetchRateHistory`) emit best-effort backdated traces with `startTime`, `success`, and `errorName` attributes - Tracing is isolated from fetch/retry logic; trace failures do not impact queries ## @metamask/chomp-api-service ## [4.0.0] ### Added - Add `getAssociatedAddresses` method, exposed as the `ChompApiService:getAssociatedAddresses` messenger action, which fetches the active address associations of the authenticated profile via `GET /v1/auth/address` ([MetaMask#9387](MetaMask#9387)) - Also adds the `ProfileAddressEntry` type describing each returned entry and the `ChompApiServiceGetAssociatedAddressesAction` type - Returned addresses are parsed into canonical lowercase form, entries are guaranteed to have `status: 'active'`, and results are never served from cache - The query cache key is scoped to the authenticated profile via a SHA-256 digest of the bearer token, so concurrent calls only share an in-flight request when they are for the same profile and one profile's associations are never cached under another's key ### Changed - **BREAKING:** `associateAddress` now throws an `HttpError` on a 409 response instead of returning the parsed body ([MetaMask#9387](MetaMask#9387)) - A 409 from `POST /v1/auth/address` indicates the address is associated with a _different_ profile; the previous handling attempted to parse the error body as an association result and failed with a confusing validation error. An address already associated with the authenticated profile is reported via a 201 response with `status: 'active'`, which is unchanged. - Bump `@metamask/utils` from `^11.9.0` to `^11.11.0` ([MetaMask#9074](MetaMask#9074)) - Bump `@metamask/controller-utils` from `^12.0.0` to `^12.3.0` ([MetaMask#8774](MetaMask#8774), [MetaMask#9058](MetaMask#9058), [MetaMask#9083](MetaMask#9083), [MetaMask#9218](MetaMask#9218)) - Bump `@metamask/base-data-service` from `^0.1.2` to `^0.1.3` ([MetaMask#8799](MetaMask#8799)) - Bump `@metamask/messenger` from `^1.2.0` to `^2.0.0` ([MetaMask#9392](MetaMask#9392)) - Update `LICENSE` text ([MetaMask#9472](MetaMask#9472)) ## @metamask/money-account-upgrade-controller ## [3.0.0] - **BREAKING:** Add persisted state tracking fully upgraded accounts ([MetaMask#9500](MetaMask#9500)) - `MoneyAccountUpgradeControllerState` changes from `Record<string, never>` to `{ upgradedAccounts }`, keyed by lowercased account address. Each entry records when the upgrade sequence completed and a fingerprint of the config it completed under (see new `MoneyAccountUpgradeStatus` type). Code constructing the state type (e.g. `{}` in tests or default-state maps) must include `upgradedAccounts`. - The constructor now accepts an optional `state` option, merged with the defaults; add `getDefaultMoneyAccountUpgradeControllerState` to construct those defaults. - Add `TerminalUpgradeError` and `isTerminalMoneyAccountUpgradeError`, and a `terminal` property on `MoneyAccountUpgradeStepError`, marking failures that cannot resolve by retrying — currently an account delegated to a third-party EIP-7702 implementation, an account with unexpected on-chain code, or an address confirmed to be associated with a different CHOMP profile ([MetaMask#9500](MetaMask#9500)) - The controller does not retry on its own; clients implementing their own retry logic around `upgradeAccount` can use `isTerminalMoneyAccountUpgradeError` to stop retrying failures that cannot succeed. ### Changed - **BREAKING:** The `associate-address` upgrade step now checks the profile's existing address associations via `ChompApiService:getAssociatedAddresses` before signing, and reports `already-done` without signing or submitting anything when the address is already associated ([MetaMask#9387](MetaMask#9387)) - `MoneyAccountUpgradeControllerMessenger` consumers must grant the `ChompApiService:getAssociatedAddresses` action alongside the previously required actions, and must provide a `@metamask/chomp-api-service` version that registers it (`>=4.0.0`). - The lookup is an optimization: if it fails, the step falls through to the previous sign-and-submit behavior. - A 409 conflict from the association request is disambiguated by re-fetching the associations, so a same-profile create race reports `already-done` instead of failing the upgrade; a genuine conflict (address associated with a different profile) still fails the step. - `upgradeAccount` now skips the step sequence entirely when the account is recorded in state as upgraded under the active config fingerprint, and records the account after a successful run. If the chain, CHOMP contract addresses, or Delegation Framework version change, the fingerprint no longer matches and the sequence re-runs ([MetaMask#9500](MetaMask#9500)) - Bump `@metamask/messenger` from `^1.2.0` to `^2.0.0` ([MetaMask#9392](MetaMask#9392)) - Bump `@metamask/authenticated-user-storage` from `^3.0.0` to `^3.0.1` ([MetaMask#9458](MetaMask#9458)) - Bump `@metamask/chomp-api-service` from `^3.1.0` to `^4.0.0` ([MetaMask#9586](MetaMask#9586)) <!-- 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] > **High Risk** > Multiple breaking releases affect CHOMP address association error handling and Money account upgrade state/messenger permissions; consumers must adopt new versions and migration steps together. > > **Overview** > **Monorepo release `1137.0.0`** — version bumps, finalized changelogs, and `yarn.lock` alignment for Money/CHOMP packages (no new implementation in this diff beyond release metadata). > > **`@metamask/chomp-api-service@4.0.0` (breaking):** ships `getAssociatedAddresses` and changes **`associateAddress`** to **throw on HTTP 409** instead of parsing the error body. > > **`@metamask/money-account-upgrade-controller@3.0.0` (breaking):** persisted **`upgradedAccounts`** state (config fingerprint), **terminal upgrade errors**, associate-address pre-check via **`getAssociatedAddresses`**, and **409 disambiguation**; depends on **`chomp-api-service@^4.0.0`**. > > **`@metamask/money-account-api-data-service@0.3.0`:** optional constructor **`trace`** callback for Money API HTTP calls. **`money-account-balance-service`** only bumps that dependency to `^0.3.0` (changelog under Unreleased; no package version bump in this diff). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit edd0ba1. 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: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
PR: GET-first address association for the Money Account upgrade flow
Repos: MetaMask/core → metamask-mobile (adoption to follow)
Packages:
@metamask/chomp-api-service(breaking → 4.0.0),@metamask/money-account-upgrade-controller(breaking → 3.0.0)Explanation
The
associate-addressstep of the Money Account upgrade flow currently signs aCHOMP Authenticationmessage and POSTs it to/v1/auth/addresson every run,relying on the response to discover that the address was already associated. That
means a keyring signing operation happens even when there is nothing to do.
This PR makes the step check first and sign only when needed:
@metamask/chomp-api-service: addsgetAssociatedAddresses()(
GET /v1/auth/address), which returns the authenticated profile's activeaddress associations. Results are parsed into canonical form (lowercased
addresses,
statusguaranteed'active') and are never served from cache,since the response is scoped to the authenticated profile and consumers use it
to decide whether to sign.
@metamask/money-account-upgrade-controller: theassociate-addressstepnow calls the new action first and reports
already-done— without touchingthe keyring — when the address is already associated. The lookup is an
optimization: if it fails, the step falls through to the previous
sign-and-submit behaviour.
While verifying the endpoint's semantics against the CHOMP API source, I found
that the existing 409 handling was wrong. CHOMP returns
201 +
status: 'active'when the address is already associated with theauthenticated profile; a 409 means the address is associated with a
different profile (or, rarely, that two same-profile requests raced on the
initial create). The old code treated 409 as a success case and tried to parse
its error body as an association result, which would have failed with a
confusing validation error. Now:
associateAddressthrows anHttpErroron any non-OK response (breaking).race resolves to
already-done; a genuine cross-profile conflict fails thestep with a clear error.
The controller change is breaking because
MoneyAccountUpgradeControllerMessengerconsumers must now grant
ChompApiService:getAssociatedAddressesand pair itwith
@metamask/chomp-api-service>= 4.0.0.References
Checklist
Note
Medium Risk
Breaking API and messenger contract changes affect all Chomp
associateAddresscallers and upgrade-controller integrators; behavior touches authenticated profile–address binding and upgrade flow failure modes.Overview
Adds
getAssociatedAddresses(GET /v1/auth/address) to@metamask/chomp-api-service, with messenger actionChompApiService:getAssociatedAddresses,ProfileAddressEntrytyping, lowercase address parsing, and no durable cache (profile-scoped query key via SHA-256 of the bearer token so tokens are not exposed in cache events).Breaking:
associateAddressnow throwsHttpErroron 409 instead of treating it as success; same-profile “already associated” remains 201 +status: 'active'.The
associate-addressupgrade step calls the GET first and returnsalready-donewithout keyring signing when the address is already linked; lookup failures still fall through to sign-and-submit. On POST 409, it re-fetches associations to distinguish a benign same-profile race from a real cross-profile conflict.Breaking for consumers:
MoneyAccountUpgradeControllermust delegateChompApiService:getAssociatedAddressesand use@metamask/chomp-api-service>= 4.0.0.Reviewed by Cursor Bugbot for commit cba10e0. Bugbot is set up for automated code reviews on this repo. Configure here.