ci: fail upload when a build is in review

[tommasini]

Description

Instead of rejecting a build in review, fail uploading while there is a build in review.

Changelog

CHANGELOG entry:

Related issues

Fixes:

Manual testing steps

Feature: my feature name

  Scenario: user [verb for user action]
    Given [describe expected initial app state]

    When user [verb for user action]
    Then [describe expected outcome]

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.

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 to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

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
Changes CI release behavior for TestFlight external distribution by swallowing specific submission failures, which could mask real upload issues if the error matching is too broad.

Overview
Updates ios/fastlane/Fastfile to stop rejecting builds that are already Waiting for Review by setting reject_build_waiting_for_review: false.

Wraps upload_to_testflight in error handling so that when distribute_external is enabled and Apple rejects submission due to an existing in-review build, the lane logs a warning and continues (keeping the build uploaded for internal testers) while re-raising all other errors.

^{Reviewed by Cursor Bugbot for commit 3230953. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

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.

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: None (no tests recommended)
• Selected Performance tags: None (no tests recommended)
• Risk Level: low
• AI Confidence: 98%

click to see 🤖 AI reasoning details

E2E Test Selection:
The only changed file is ios/fastlane/Fastfile, which is a CI/CD deployment configuration file for uploading iOS builds to TestFlight. The changes are:

1. Changed reject_build_waiting_for_review from true to false — this prevents the upload process from cancelling builds already waiting for Apple review.
2. Added a begin/rescue error handling block around upload_to_testflight to gracefully handle the scenario where Apple rejects a new submission because another build is already in review queue.

These changes are purely operational/infrastructure changes to the iOS build distribution pipeline. They have zero impact on:

• App source code or functionality
• E2E test infrastructure or test files
• Any controllers, components, or user flows
• Any shared components that could break existing tests

No E2E tests need to run for this change. It's a deployment script adjustment that only affects how TestFlight uploads are handled in CI.

Performance Test Selection:
The change is purely to the iOS Fastlane deployment script (TestFlight upload configuration). It has no impact on app performance, rendering, data loading, or any user-facing functionality. No performance tests are needed.

View GitHub Actions results

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud