Skip to content

[pull] main from MetaMask:main#573

Merged
pull[bot] merged 5 commits intoReality2byte:mainfrom
MetaMask:main
May 8, 2026
Merged

[pull] main from MetaMask:main#573
pull[bot] merged 5 commits intoReality2byte:mainfrom
MetaMask:main

Conversation

@pull
Copy link
Copy Markdown

@pull pull Bot commented May 8, 2026

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 : )

mcmire and others added 5 commits May 8, 2026 14:09
## 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?
-->

A recent commit changed the `update-changelog` workflow so that instead
of checking out the release PR branch directly, it checks out the base
branch and then overlays files from the release PR that are necessary to
run `auto-changelog validate`.

Currently, only changelogs are copied from the release PR. However, to
determine which dependency bump changelog entries are missing, the
`auto-changelog validate` command needs not only changelogs but also
package manifests.

This commit fixes the `update-changelog` workflow accordingly.

## 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]
> **Low Risk**
> Low risk workflow-only change that adjusts which files are checked
out/committed and how a commit SHA is captured; main risk is unintended
CI behavior or pushes to PR branches.
> 
> **Overview**
> Fixes the `update-changelogs` GitHub Actions workflow to overlay and
temporarily commit both `**/CHANGELOG.md` *and* `**/package.json` from
the PR branch before running `yarn changelog:validate --checkDeps`,
ensuring dependency-bump validation uses the PR’s manifests.
> 
> Also updates the workflow to output the full commit SHA (`%H`) for the
generated changelog-fix commit, and renames the related steps to reflect
the broader file overlay/commit.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
bd50247. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
## @metamask/chain-agnostic-permission

## [1.6.0]

### Added

- Add `Eip1193Compatible` property in `KnownSessionProperties` enum to
support EIP-1193-style connections established through `connect-evm`
([#8731](#8731))
- Set `sessionProperties: { 'eip1193-compatible': true }` in
`getCaip25PermissionFromLegacyPermissions` so that legacy EIP-1193
permission requests are tagged as EIP-1193-compatible
([#8731](#8731))

### Changed

- Bump `@metamask/permission-controller` from `^12.2.1` to `^13.1.0`
([#8317](#8317),
[#8661](#8661),
[#8722](#8722))
- Bump `@metamask/controller-utils` from `^11.19.0` to `^11.20.0`
([#8344](#8344))

## @metamask/multichain-api-middleware

## [3.1.0]

### Changed

- Bump `@metamask/chain-agnostic-permission` from `^1.5.0` to `^1.6.0`
([#8290](#8749))
- Bump `@metamask/multichain-transactions-controller` from `^7.0.4` to
`^7.1.0` ([#8665](#8665))
- Bump `@metamask/accounts-controller` from `^37.2.0` to `^38.0.0`
([#8665](#8665))
- Bump `@metamask/permission-controller` from `^13.0.0` to `^13.1.0`
([#8722](#8722))
- Bump `@metamask/json-rpc-engine` from `^10.3.0` to `^10.4.0`
([#8746](#8746))

<!-- CURSOR_SUMMARY -->
---

> [!NOTE]
> **Low Risk**
> Primarily version/changelog updates and dependency range bumps; no
functional source changes are included in this diff, so runtime risk is
low aside from typical release packaging/versioning issues.
> 
> **Overview**
> Bumps the monorepo release version to `971.0.0` and publishes new
package versions for `@metamask/chain-agnostic-permission` (`1.6.0`) and
`@metamask/multichain-api-middleware` (`3.1.0`).
> 
> Updates changelogs and lockfile, and bumps downstream dependencies
(`@metamask/eip1193-permission-middleware` and
`@metamask/multichain-api-middleware`) to consume
`@metamask/chain-agnostic-permission@^1.6.0`.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
90d6560. 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?
-->

When TypeScript type-checks arguments to `Messenger.delegate` and
`Messenger.revoke` it can produce the error "Expression produces a union
type that is too complex to represent" if the delegatee contains a large
number of capabilities and/or there are large number of capabilities
being delegated or revoked. This happens because when TypeScript
evaluates `MessengerActions<Delegatee> & Action` or
`MessengerEvents<Delegatee> & Event` it needs to recursively compute
every combination of action/event type — handlers, types used within
handlers, everything. The possibility of this error has always been
present, but was excerbated by recent changes to the `InternalAccount`
type in `keyring-api`, which added support for Tron and Stellar.

All of this computing is wasteful. All we really need is an intersection
of action/event type strings. This commit changes the types for
`DelegatedActions` and `DelegatedEvents` to reflect this fact. These
changes should be type-compatible since the end result is still the
same.

## 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
-->

Recently a change was made in Mobile to work around this problem. See:
MetaMask/metamask-mobile#29621

## 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**
> Public TypeScript API typings for
`Messenger.delegate`/`Messenger.revoke` change, which could affect
downstream type-checking even though runtime behavior is untouched. Risk
is limited to compile-time compatibility and inference/regression in
complex consumer typings.
> 
> **Overview**
> Reduces TypeScript type-checker blowups in `Messenger.delegate` and
`Messenger.revoke` by narrowing `DelegatedActions`/`DelegatedEvents` to
intersections of action/event **type strings** (rather than intersecting
full action/event unions), aiming to avoid TS2590 “union type too
complex” errors.
> 
> Updates the messenger package changelog to note the fix under
*Unreleased*.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
cdf1305. 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?
-->

When an engineer opens a release PR, they may want to make additional
changes to the release plan before they are ready to open the PR, and so
they may not want to populate dependency bump entries across changelogs
right away. To account for this, this commit modifies the
`update-changelogs` workflow so that the initial run only occurs if the
PR is created in non-draft status or is taken out of draft otherwise.

## 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]
> **Low Risk**
> Low risk workflow gating change; it only adjusts when the GitHub
Actions job runs and does not affect production code paths.
> 
> **Overview**
> Updates the `update-changelogs` GitHub Actions workflow to **not run
automatically for draft PRs**.
> 
> The workflow now triggers on `pull_request_target` `ready_for_review`
and tightens the `is-fork` job condition so the initial run only occurs
when the PR is *not* a draft (while still allowing manual runs via
`@metamaskbot update-changelogs` comments).
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
f8a1fc0. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
…onfig with remote feature flag subscription (#8742)

## 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?
-->

This PR updates the `@metamask/money-account-balance-service` to use a
remote vault config instead of constructor args.

## 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
-->

- [MUSD-681: Support remote vault config feature flag in Money Balance
Service](https://consensyssoftware.atlassian.net/browse/MUSD-681)

## 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 API changes shift vault configuration from constructor args
to `RemoteFeatureFlagController` state and alter response shapes, which
can break consumers and affect balance/APY lookups until flags are
available. Runtime behavior now depends on async flag delivery and
validation, adding new error paths and cache invalidation logic.
> 
> **Overview**
> Refactors `MoneyAccountBalanceService` to **stop taking vault config
in the constructor** and instead `init()`/subscribe to
`RemoteFeatureFlagController` (`getState` + `stateChange`) for a remote
`moneyAccountVaultConfig`, throwing `VaultConfigNotAvailableError` until
a valid config is present and routing malformed configs via
`VaultConfigValidationError`.
> 
> Updates on-chain/API fetching to use the new config shape
(`boringVault`, `chainId`, `lensAddress`, `tellerAddress`, etc.),
including switching `getMusdEquivalentValue` to call the Lens contract’s
`balanceOfInAssets` and tightening `getVaultApy` to error when the chain
ID lacks a `VEDA_API_NETWORK_NAMES` mapping (adds Monad). Adds
corresponding structs/types, logging, exports, dependency on
`@metamask/remote-feature-flag-controller`, and extensive test coverage
for config lifecycle and cache invalidation.
> 
> <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit
5e603a6. Bugbot is set up for automated
code reviews on this repo. Configure
[here](https://www.cursor.com/dashboard/bugbot).</sup>
<!-- /CURSOR_SUMMARY -->
@pull pull Bot locked and limited conversation to collaborators May 8, 2026
@pull pull Bot added the ⤵️ pull label May 8, 2026
@pull pull Bot merged commit f7df669 into Reality2byte:main May 8, 2026
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants