fix: Add hasTransactionType helper to transaction-controller - #9570
Merged
Conversation
OGPoyraz
marked this pull request as ready for review
July 21, 2026 10:54
OGPoyraz
enabled auto-merge
July 21, 2026 10:58
pedronfigueiredo
approved these changes
Jul 21, 2026
pull Bot
pushed a commit
to dmrazzy/core
that referenced
this pull request
Jul 22, 2026
## Explanation Release `1136.0.0` with minor version bumps for: - `@metamask/transaction-controller` `69.1.0` → `69.2.0` - `@metamask/transaction-pay-controller` `25.0.0` → `25.1.0` ### `@metamask/transaction-controller@69.2.0` #### Added - Export `hasTransactionType` helper for checking a transaction's type against the top-level `TransactionMeta` and any nested transactions ([MetaMask#9570](MetaMask#9570)) ### `@metamask/transaction-pay-controller@25.1.0` #### Changed - Consume `hasTransactionType` helper from `@metamask/transaction-controller` to derive relevant transaction type against the top-level `TransactionMeta` ([MetaMask#9570](MetaMask#9570)) - Bump `@metamask/transaction-controller` from `^69.0.0` to `^69.2.0` - Bump `@metamask/assets-controller` from `^11.0.0` to `^11.1.0` ### Dependency updates 17 packages had their `@metamask/transaction-controller` dependency range updated to `^69.2.0` with corresponding changelog entries: - **15 packages** had existing `^69.0.0 → ^69.1.0` entries updated to `^69.0.0 → ^69.2.0`: `assets-controller`, `assets-controllers`, `bridge-controller`, `bridge-status-controller`, `client-utils`, `eip-5792-middleware`, `gator-permissions-controller`, `network-enablement-controller`, `phishing-controller`, `profile-metrics-controller`, `shield-controller`, `smart-transactions-controller`, `subscription-controller`, `user-operation-controller`, `wallet` - **2 packages** received new `^69.1.0 → ^69.2.0` entries: `perps-controller`, `earn-controller` All changelog entries are under `[Unreleased]` in the respective packages. ## References - [MetaMask#9570](MetaMask#9570) — Export `hasTransactionType` helper and consume in transaction-pay-controller - [MetaMask#9568](MetaMask#9568) — Bump transaction-controller to 69.1.0 ## 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 - [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** > Version and dependency-range updates only; functional changes shipped in prior PRs (MetaMask#9570). Risk is mainly consumer lockfile/coordinated upgrade, not new logic in this diff. > > **Overview** > Cuts **monorepo release `1136.0.0`** and publishes **`@metamask/transaction-controller@69.2.0`** and **`@metamask/transaction-pay-controller@25.1.0`**, with changelogs/version tags updated for those packages. > > **`transaction-controller` 69.2.0** documents the exported **`hasTransactionType`** helper (top-level and nested `TransactionMeta` type checks, from [MetaMask#9570](MetaMask#9570)). **`transaction-pay-controller` 25.1.0** is bumped to consume that helper and align on **`^69.2.0`**. > > Across the workspace, **17 dependent packages** move their **`@metamask/transaction-controller`** range from **`^69.1.0`** (or consolidated **`^69.0.0 → ^69.2.0`** changelog lines) to **`^69.2.0`**, with matching **`[Unreleased]`** changelog notes and **`yarn.lock`** resolution updates. No application logic changes appear in this diff beyond versioning and dependency metadata. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b6bd83a. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
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
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.
Explanation
transaction-pay-controllerhad a localisPredictWithdrawTransactionhelper inutils/transaction.tsthat checked whether aTransactionMeta(or any of its nested transactions) has thepredictWithdrawtype. The same pattern was duplicated across multiple call sites in the Across and Relay strategies.This PR extracts that logic into a generic
hasTransactionType(transactionMeta, types)helper published from@metamask/transaction-controller, and replaces everyisPredictWithdrawTransactioncall intransaction-pay-controllerwith the new helper. The behaviour is identical — top-level type and nested transaction types are both matched — but callers can now pass any set ofTransactionTypevalues instead of being hard-coded topredictWithdraw.References
N/A
Checklist
Note
Low Risk
Refactor with equivalent predict-withdraw semantics; behavior is covered by moved/added unit tests and only affects type-check call sites, not transaction submission paths directly.
Overview
Adds a shared
hasTransactionType(transactionMeta, types)API on@metamask/transaction-controllerthat returns whether the top-levelTransactionMetatype or any nested transaction matches one of the givenTransactionTypevalues (includingundefinedtransaction and empty type lists).transaction-pay-controllerdrops localisPredictWithdrawTransactionand wires Across/Relay strategy code to the new helper forpredictWithdrawchecks (quotes, submit, authorization-list, gas estimation). Unit coverage for the matching logic moves intotransaction-type.test.tsin transaction-controller.Reviewed by Cursor Bugbot for commit 893a8b4. Bugbot is set up for automated code reviews on this repo. Configure here.