[pull] main from MetaMask:main#744
Merged
pull[bot] merged 3 commits intoReality2byte:mainfrom May 9, 2026
Merged
Conversation
## **Description**
<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->
### Problem
Nightly iOS builds for a given app version (e.g. 7.78.0) were expiring
all previous TestFlight builds, leaving only the most recent one active
in the external testing group.
As a result, every nightly upload was calling `upload_to_testflight`
with `distribute_external: true`, which causes Apple to automatically
expire the previous build in the external group each time a new one is
submitted.
### Solution
The `distribute_external` parameter is now threaded end-to-end through
the full upload chain:
- **`scripts/upload-to-testflight.sh`**: Changed the default for the 5th
argument from `true` to `false`, so callers must explicitly opt in to
external distribution.
- **`upload-to-testflight.yml`**: Added `distribute_external` as a
workflow input (default `true` for backwards compatibility with direct
callers) and passes it as the 5th argument to the script.
- **`build-and-upload-to-testflight.yml`**: Added `distribute_external`
as a workflow input (default `false` for both `workflow_call` and
`workflow_dispatch`), and threads it through to
`upload-to-testflight.yml`.
- **`nightly-build.yml`**: Explicitly passes `distribute_external: true`
for both `ios-exp` and `ios-rc` jobs, so nightly builds continue to
reach the external testing group (needed since the org exceeds the
100-person internal tester limit).
The intent is now explicit and self-documenting: nightly builds always
go to the external group, while ad-hoc manual builds (triggered via
`workflow_dispatch`) default to internal-only, avoiding accidental
expiration of the active nightly build.
## **Changelog**
CHANGELOG entry: null
## **Related issues**
No issue: CI regression fix — the issue's origin hasn't been found yet.
## **Manual testing steps**
```gherkin
Feature: TestFlight external distribution is configurable per caller
Scenario: nightly build distributes to external testers
Given the nightly-build.yml workflow is triggered on schedule
When ios-exp and ios-rc jobs run
Then distribute_external is true
And the build is added to the "MetaMask BETA & Release Candidates" external group
And previous builds for the same version are expired by Apple (expected Apple behaviour for external groups)
Scenario: manual workflow_dispatch build does not expire the active nightly build
Given a developer triggers build-and-upload-to-testflight.yml via workflow_dispatch
And does not explicitly set distribute_external
When the upload runs
Then distribute_external defaults to false
And the build is uploaded to TestFlight as internal-only
And the active nightly build in the external group is not expired
Scenario: explicit external distribution via workflow_dispatch
Given a developer triggers build-and-upload-to-testflight.yml via workflow_dispatch
And sets distribute_external to true
When the upload runs
Then the build is added to the selected external testing group
```
## **Screenshots/Recordings**
### **Before**
N/A
### **After**
N/A
## **Pre-merge author checklist**
<!--
Every checklist item must be consciously assessed before marking this PR
as
"Ready for review". A checked box means you deliberately considered that
responsibility, not that you literally performed every action listed.
Unchecked boxes are ambiguous: they are not an implicit "N/A" and they
are not
a silent "skip". See `docs/readme/ready-for-review.md` for the full
checklist
semantics.
-->
- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile
Coding
Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I've included tests if applicable
- [x] I've documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [x] I've applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.
#### Performance checks (if applicable)
- [ ] I've tested on Android
- Ideally on a mid-range device; emulator is acceptable
- [ ] I've tested with a power user scenario
- Use these [power-user
SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93)
to import wallets with many accounts and tokens
- [ ] I've instrumented key operations with Sentry traces for production
performance metrics
- See [`trace()`](/app/util/trace.ts) for usage and
[`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274)
for an example
For performance guidelines and tooling, see the [Performance
Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers).
## **Pre-merge reviewer checklist**
<!--
Reviewer checklist items follow the same semantics as the author
checklist: an
unchecked box is ambiguous, a checked box means the reviewer consciously
assessed that responsibility. See `docs/readme/ready-for-review.md`.
-->
- [ ] 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.
<!-- Generated with the help of the pr-description AI skill -->
…ions. (#29638) ## **Description** Updates usage of `withKeyring` to `withKeyringV2`. Note: Instances where `withKeyring` was not updated is considered to be dead code and will be removed in a follow up PR. ## **Changelog** CHANGELOG entry: null ## **Related issues** N/A ## **Manual testing steps** 1. Build from this branch. 2. Ensure account ux is not affected (creating accounts, importing, using hardware wallets) ## **Screenshots/Recordings** N/A - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [x] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [x] 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. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Updates the keyring access method used when importing/restoring mnemonics, which can impact account selection/address retrieval during onboarding and seedless flows. Limited scope but touches wallet import/authentication paths where regressions would be user-visible. > > **Overview** > Switches mnemonic import flows to use `KeyringController.withKeyringV2` when retrieving the first account address after creating a multichain wallet (in `actions/multiSrp.importNewSecretRecoveryPhrase` and `Authentication.importSeedlessMnemonicToVault`). > > Removes the unused `createNewSecretRecoveryPhrase` action and its associated unit tests, and updates the `multiSrp` tests to mock `withKeyringV2` accordingly. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 2e9b628. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
## **Description** Adds Deposit Wallet support for the Predict claim flow. Polymarket Deposit Wallet users still create a normal MetaMask claim confirmation so the transaction is visible in activity, but the signed confirmation transaction is not published directly. Instead, Predict intercepts pending claim transactions in the publish hook, submits the actual claim calls as a Polymarket Deposit Wallet relayer `WALLET` batch, waits only until the relayer returns a transaction hash, and returns that hash to TransactionController. This PR preserves legacy Safe claim behavior: Safe users continue to sign and publish the existing Safe claim transaction path. Key changes: - Add Deposit Wallet claim planning that builds relayer calls from claimable positions. - Mark Deposit Wallet claim confirmation transactions as externally signed before signing. - Publish Deposit Wallet claims through the relayer batch and return as soon as a transaction hash is available. - Trigger best-effort CLOB balance-allowance sync after confirmed claims. - Wire Predict pending-claim context into `beforeSign` and `publish`. - Add `skipInitialGasEstimate` to claim confirmation batch creation. ## **Changelog** CHANGELOG entry: Fixed Predict claims for Polymarket Deposit Wallet users. ## **Related issues** Fixes: [PRED-859](https://consensyssoftware.atlassian.net/browse/PRED-859) ## **Manual testing steps** ```gherkin Feature: Predict Deposit Wallet claim flow Scenario: Deposit Wallet user claims resolved positions Given a Predict user is routed to a Polymarket Deposit Wallet And the user has claimable positions When the user starts the claim flow Then MetaMask shows the normal claim confirmation When the user approves the confirmation Then the claim is submitted through the Polymarket Deposit Wallet relayer And MetaMask activity tracks the returned transaction hash Scenario: legacy Safe user claims resolved positions Given a Predict user is routed to a legacy Safe wallet And the user has claimable positions When the user approves the claim confirmation Then the existing Safe claim publish path is used ``` ## **Screenshots/Recordings** ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] 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](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **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. [PRED-859]: https://consensyssoftware.atlassian.net/browse/PRED-859?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes claim transaction `beforeSign`/`publish` behavior and introduces a new relayer-based submission path for deposit-wallet users, which could affect transaction lifecycle and activity tracking if metadata or batch matching is wrong. > > **Overview** > Adds **deposit-wallet support for Predict claims** by intercepting pending `predictClaim` transactions in `PredictController` and delegating `beforeSign`/`publish` to new provider hooks (`beforeSignClaim`, `publishClaim`). Deposit-wallet claims are now marked as *externally signed* before signing and are published via a Polymarket relayer `WALLET` batch (planned by new `planDepositWalletClaim`) while legacy Safe claims continue to pass through. > > Claim batch submission is tweaked to set `skipInitialGasEstimate` and include the MATIC collateral gas token, and `confirmClaim` now triggers a best-effort deposit-wallet collateral allowance sync after claim confirmation. Tests are expanded/added across `PredictController`, `PolymarketProvider`, and new `preflight/claim` coverage for requirement filtering and call ordering. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c11a3c6. 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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 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 : )