feat: display errors coming from the snaps when submitting confirm in send flow by Julink-eth · Pull Request #25648 · MetaMask/metamask-mobile

Julink-eth · 2026-02-04T14:28:20Z

Description

Adds proper error handling for non-EVM transaction submissions. When a multichain snap (Solana, Tron) returns validation errors during send, the error is displayed on the Continue button so users can correct the issue.

Added submitError state to SendContext with auto-clear on input changes
Display snap validation errors on the Amount screen's Continue button
Navigate back 2 screens to Amount when submission fails
Bumped @metamask/tron-wallet-snap to ^1.20.0

Related Extension PR: MetaMask/metamask-extension#39667

Changelog

CHANGELOG entry: Validation errors from non-EVM transaction snaps will now be displayed to users during send flow.

Related issues

Fixes: https://consensyssoftware.atlassian.net/jira/software/c/projects/NEB/boards/3738?assignee=62710850d7fd480068d7cff9&selectedIssue=NEB-385

Manual testing steps

Feature: Display snap validation errors in send flow

  Scenario: User sees Insufficient balance to cover fees error on Tron send
    Given user has a Tron account with a balance > 10 TRX

    When user attempts to send all his balance to a non activated account(Any account that never received TRX before)
    Then the snap returns a validation error
    And user is navigated back to Amount screen
    And the Continue button displays "Insufficient balance to cover fees error" with danger styling

  Scenario: User clears error by changing amount
    Given user sees an error on the Continue button

    When user changes the amount
    Then the error is cleared and button shows "Continue"

Screenshots/Recordings

Before

After

Pre-merge author checklist

I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
I've completed the PR template to the best of my ability
I've included tests if applicable
I've documented my code using JSDoc format if applicable
I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

Note

Medium Risk
Adds new error-handling paths for non-EVM snap transaction submission, which can change user flow and messaging. Risk is moderate due to reliance on snap return shapes and new branching around navigation/alerts.

Overview
Non-EVM send submission now surfaces snap validation failures and internal errors to users instead of silently ignoring them.

useSendActions inspects the sendMultichainTransactionForReview result for valid: false, maps snap error codes to localized messages, and shows an Alert (falling back to a new generic send.transaction_error string when no error details are provided). It also distinguishes user rejection via errorCodes.provider.userRejectedRequest to avoid showing an error UI.

Adds unit tests covering non-EVM snap validation errors (with/without an errors array), specific code translations, user rejection behavior, generic failures, and successful navigation; and exports mapSnapErrorCodeIntoTranslation for reuse.

^{Written by Cursor Bugbot for commit 719916c. This will update automatically on new commits. Configure here.}

… send flow

github-actions · 2026-02-04T14:28:32Z

CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes.

app/components/Views/confirmations/hooks/send/useSendActions.ts

app/components/Views/confirmations/components/send/recipient/recipient.tsx

app/components/Views/confirmations/hooks/send/useSendActions.ts

OGPoyraz · 2026-02-05T13:01:38Z

app/components/Views/confirmations/components/send/amount/amount-keyboard/amount-keyboard.tsx

Extension is two step (asset => amount and recipient ) meanwhile mobile is (asset => amount => recipient). I understood that we blocked the button in the last page in extension but why would submission error is having effect in the amount page in mobile?

If the amount is an issue to submit this transaction - error should be raised upfront by authorized snap validateNonEvmAmount in app/components/Views/confirmations/hooks/send/useAmountValidation.ts.

We can't raise upfront as we are missing params to be sent to the snap for it to run the tx simulation, we don't send the recipient param at this stage, hence why we can only raise it in the confirm screen.
Also this allows to be aligned with the extension behavior no ?

I thought both extension and mobile PRs were intending just to handle exceptions when snap confirmation couldn't be created.

But this conversation already happened before and decided that those errors will be surfaced in the snap confirmation, discussion here: https://consensys.slack.com/archives/C099HFE1ZHA/p1769606213847949?thread_ts=1769519715.568409&cid=C099HFE1ZHA

As recipient page is final step before snap confirmation, this error should be surfaced there and only. Then user can go back and change the amount - I see no reason of bringing complexity into amount page only for Tron exception.

So you'd display the error message in a popup in the recipient screen, is it something we do ? Because I haver never seen an error in this screen.
Also the reason I displayed it in the amount screen is because I saw that the button was commonly used for this reason.

So you'd display the error message in a popup in the recipient screen, is it something we do ? Because I haver never seen an error in this screen.

We don't do that today. That would be awesome - but not fair to ask to implement in this PR. Because imagine - you don't really need to handle all the context additions, we could directly raise an Alert which would be more clear.

In fact - I was meaning to put that message in to this button as user final attempt was on the recipient screen, see recording:

Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-02-06.at.10.10.50.mov

OGPoyraz · 2026-02-05T13:03:23Z

app/components/Views/confirmations/context/send-context/send-context.tsx

Rather than pushing the error state into send-context, can't we capsulate it in the recipient page if transaction submission done by the button in that page?

If we remove it from the send-context we would have to add it in the amount-keyboard.tsx as well would that be fine ?

OGPoyraz · 2026-02-05T13:07:05Z

app/components/Views/confirmations/hooks/send/useSendActions.ts

+          if (result?.valid === false) {
+            const errorMessage = result?.errors?.length
+              ? mapSnapErrorCodeIntoTranslation(result.errors[0].code)
+              : strings('send.transaction_error');
+            updateSubmitError(errorMessage);
+            // Navigate back to the Amount screen where the error can be displayed
+            // (Recipient screen may not have a visible button when recipient is selected from list)
+            if (screensToPopOnError > 0) {
+              (navigation as StackNavigationProp<ParamListBase>).pop(
+                screensToPopOnError,
+              );
+            }
+            return;
+          }


Apologies - I forgot to ask this question in extension PR but just noticed now.

What conditions we get result?.valid === false and what conditions that sendMultichainTransactionForReview will throw? One is userRejection but can't we simplify it to throw in the snap code always?

Trying to handle both cases looks a bit of duplication to me.

Those are the conditions for result?.valid === false: (For tron at least, snaps are not aligned)
https://github.com/MetaMask/snap-tron-wallet/blob/5febcaf0c581ff8c76c92a3ec9c7557c10613fb9/packages/snap/src/handlers/clientRequest/clientRequest.ts#L419

We could always throw but that means aligning all the snaps and this PR is part of the tron snap issues that need to be resolved rather quickly for dapps connectivity release.

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

app/components/Views/confirmations/hooks/send/useSendActions.ts

github-actions · 2026-02-06T13:39:35Z

🔍 Smart E2E Test Selection

Selected E2E tags: SmokeConfirmations, SmokeNetworkExpansion
Selected Performance tags: None (no tests recommended)
Risk Level: medium
AI Confidence: 90%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are focused on improving error handling for non-EVM (Solana/multichain) send transactions in the confirmations flow:

useAmountValidation.ts: Exports mapSnapErrorCodeIntoTranslation function (previously private) to allow reuse in useSendActions.ts
useSendActions.ts: Enhanced error handling for multichain transactions:
- Handles snap validation errors (when valid: false is returned with error codes)
- Shows appropriate error alerts for snap/internal errors
- Detects user rejection (error code 4001) to avoid showing alerts for intentional cancellations
- Navigates to transactions view on success
useSendActions.test.ts: Comprehensive tests for the new non-EVM send error handling
en.json: Added "transaction_error" translation string

These changes directly affect:

SmokeConfirmations: The changes are in confirmations hooks for send functionality, which tests "transaction sending for native tokens (ETH), ERC-20 tokens, and Solana SPL tokens"
SmokeNetworkExpansion: The changes specifically handle Solana/non-EVM transaction flows via multichain snaps, which tests "SOL token transfers" and "non-EVM blockchain support"

Per tag guidance: "When selecting SmokeNetworkExpansion for Solana transaction or signing flows, also select SmokeConfirmations"

Performance Test Selection:
The changes are focused on error handling logic for non-EVM send transactions. They add Alert.alert calls for error cases and improve the control flow for error scenarios. These changes do not affect UI rendering performance, data loading, list rendering, or app startup. The changes are purely functional improvements to error handling and do not introduce any performance-sensitive code paths.

View GitHub Actions results

sonarqubecloud · 2026-02-06T14:01:28Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

feat: display errors coming from the snaps when submitting confirm in…

a1d83d7

… send flow

metamaskbot added the team-network-enablement label Feb 4, 2026

Julink-eth changed the title ~~feat: display errors coming from the snaps when submitting confirm in…~~ feat: display errors coming from the snaps when submitting confirm in send flow Feb 4, 2026

github-actions bot added the size-M label Feb 4, 2026

Julink-eth added 2 commits February 4, 2026 17:34

chore: fix lint

71b89ef

fix: unit test

2bcbe43

Julink-eth marked this pull request as ready for review February 4, 2026 17:19

Julink-eth requested a review from a team as a code owner February 4, 2026 17:19

Julink-eth added this to PR review queue Feb 4, 2026

Julink-eth moved this to Needs dev review in PR review queue Feb 4, 2026

cursor bot reviewed Feb 4, 2026

View reviewed changes

Julink-eth added 2 commits February 5, 2026 11:33

chore: address cursor's comments

83ded8c

fix: unit test

df2e139

OGPoyraz requested changes Feb 5, 2026

View reviewed changes

github-project-automation bot moved this from Needs dev review to Needs more work from the author in PR review queue Feb 5, 2026

OGPoyraz mentioned this pull request Feb 5, 2026

feat: display errors coming from the snaps when submitting confirm in send flow MetaMask/metamask-extension#39667

Merged

7 tasks

Julink-eth added 3 commits February 6, 2026 12:12

chore: move the alert to the confirm screen using react Alert

c5adc91

chore: remove unecessary changes

1448c3f

chore: merge main

57f75cc

cursor bot reviewed Feb 6, 2026

View reviewed changes

app/components/Views/confirmations/hooks/send/useSendActions.ts Show resolved Hide resolved

chore: merge main

719916c

OGPoyraz approved these changes Feb 6, 2026

View reviewed changes

github-project-automation bot moved this from Needs more work from the author to Review finalised - Ready to be merged in PR review queue Feb 6, 2026

Julink-eth added this pull request to the merge queue Feb 6, 2026

Merged via the queue into main with commit 19705ab Feb 6, 2026
94 checks passed

Julink-eth deleted the feat/handle-error-messages-in-submit-send branch February 6, 2026 14:51

github-actions bot locked and limited conversation to collaborators Feb 6, 2026

metamaskbot added the release-7.66.0 Issue or pull request that will be included in release 7.66.0 label Feb 6, 2026

Uh oh!

Conversation

Julink-eth commented Feb 4, 2026 • edited by cursor bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Changelog

Related issues

Manual testing steps

Screenshots/Recordings

Before

After

Pre-merge author checklist

Pre-merge reviewer checklist

Uh oh!

github-actions bot commented Feb 4, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

OGPoyraz Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cursor bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions bot commented Feb 6, 2026

🔍 Smart E2E Test Selection

Uh oh!

sonarqubecloud bot commented Feb 6, 2026

Quality Gate passed

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Julink-eth commented Feb 4, 2026 •

edited by cursor bot

Loading

OGPoyraz Feb 5, 2026 •

edited

Loading