Never present a post-broadcast error as a failed send

[j0ntz]

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

• Yes
• No

Dependencies

none

Requirements

If you have made any visual changes to the GUI. Make sure you have:

• Tested on iOS device
• Tested on Android device
• Tested on small-screen device (iPod Touch)
• Tested on large-screen device (tablet)

Description

Technical design doc

GUI half of Edge bug "Send - multiple transactions after network error": one intended Bitcoin send became five real payments. Every broadcast succeeded; the engine's saveTx then threw, and the send scene treated that throw as a failed send: error card blaming the network plus a re-armed slider. Each retry re-quoted on the remaining UTXOs (saveTx marks inputs spent before it throws), so each slide was a fresh real payment. Three distinct payments happened inside 44 seconds in the incident log.

Asana: https://app.asana.com/1/9976422036640/project/1213843652804305/task/1217135300337949

The submit flow in SendScene2.handleSliderComplete is now split at the broadcast boundary:

• broadcastedTx is hoisted above the try block; once it is set, the funds have moved.
• A post-broadcast throw is logged (logActivity), surfaced as a warning that the transaction WAS sent ("sent, but some final bookkeeping did not complete"), and navigates forward exactly like a success (onDone / transaction details).
• The finally block only re-arms the slider when nothing was broadcast. A genuinely failed broadcast (throw before broadcastTx returns) keeps the existing error card and retry behavior.
• handleSliderComplete returns the broadcast transaction so the FIO no-bundled retry (which recursively awaits it) propagates a nested broadcast to the outer invocation; without that, the outer finally could re-arm the slider after the nested attempt broadcast (caught by Bugbot in review).

Verified on the iOS sim against Bitcoin testnet with a real broadcast and an injected post-broadcast throw, before and after the fix (screenshots below). The engine half (saveTx resolving on a not-running engine, broadcast-failure classification with BroadcastAmbiguityError) is EdgeApp/edge-currency-plugins#455; this scene does not consume the ambiguity classification yet (the lock-on-ambiguous-failure UX is tracked separately).

---

Note

High Risk
Changes core send confirmation behavior and slider retry logic in the payment path; incorrect boundary handling could still mislead users or allow duplicate sends.

Overview
Send now treats a successful broadcast as final even when later steps (metadata, FIO record, navigation hooks) throw. That closes the path where one intended send could become several real payments after engine bookkeeping failed but the tx was already on the network.

SendScene2.handleSliderComplete hoists broadcastedTx above the try block and uses it as the broadcast boundary. After broadcastTx succeeds, any catch path logs the error, shows a warning (transaction_success_bookkeeping_error_message) instead of a failure card, and navigates forward via shared navigateForwardAsSent—same as a clean success. The finally block only re-arms the confirm slider when nothing was broadcast; pre-broadcast failures still show errors and allow retry.

The handler now returns the broadcasted transaction so the FIO no-bundled retry can assign a nested successful broadcast to the outer invocation and avoid re-arming the slider. SafeSlider uses a handleSlideConfirm wrapper because the slider API expects a void callback.

Adds English strings and a CHANGELOG entry; includes design doc send-post-broadcast-failure.md (pairs with engine work in edge-currency-plugins).

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

[j0ntz]

📸🪓 Test evidence (iOS sim, Bitcoin testnet, real broadcasts)

🪓 Hack-forced evidence: Uncommitted throw injected in SendScene2 right after coreWallet.broadcastTx returns (broadcast itself ran for real on testnet); frames 03/04 additionally swapped SendScene2 to develop's version for the before-fix comparison; both edits reverted, clean tree. Temporary uncommitted edit, reverted before commit; the marked frames prove the rendering, not the trigger.

🪓 HACK-FORCED: after fix warning

🪓 HACK-FORCED: after fix forward nav

🪓 HACK-FORCED: before fix error card

🪓 HACK-FORCED: before fix slider rearmed

Captured by the agent's in-app test run (build-and-test).

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[cursor]

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

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ab91beb. Configure here.}

[claude]

Claude Code Review

Claude Code Review is paused for this repository. To reconnect it, an admin of this repository's GitHub organization (or the account owner, for personal repositories) who can also manage your Claude organization's Code Review settings needs to re-link GitHub in Code Review settings. This is a one-time step.

_{Tip: disable this comment in your organization's Code Review settings.}