Swap broadcast-failure message invites retry while the signed tx can still land (hung RPC) — double-execution risk inside the deadline window #359

New issue

Closed

opened 2026-06-11 03:46:52 +00:00 by Brouie · 19 comments

Brouie commented

2026-06-11 03:46:52 +00:00

(Migrated from gitlab.com)

Found during #337 ERR-00-03 (broadcast timeout) — build 3169af0, Cosmostation, EMBER/CORAL pair.

Repro (RPC hang, not refusal — the common mainnet failure mode):

Prepared a 1 EMBER -> CORAL swap, clicked Swap, froze the chain container (sockets hang, not refuse) before approving in the wallet, then approved.
Dapp showed "Could not broadcast the transaction. Check your connection and try again." and returned to ready state.
Chain unfrozen ~2 min later: the queued broadcast flushed and the ORIGINAL tx executed clean — 36324C8CF5C65FF9C9CC33A4ABF4B647B3286DF1A5E43823AF1A0A187AB06EBE, code 0, height 1031478, the exact 1,000,000 uEMBER swap.

So the failure copy is wrong about the state and actively invites a duplicate: after signing, the tx exists; "try again" within the deadline window = double-execution. The msg-level deadline does bound the window (this tx landed inside it), but it's minutes wide — plenty of time to retry.

Suggested handling for broadcast failure AFTER signing:

The client can compute the tx hash from the signed bytes. Surface "broadcast status unknown — the transaction may still confirm", poll LCD /txs/{hash} through the deadline window before re-enabling submit, then resolve to success or definitively-not-found (only then offer retry).
Keep the current copy for PRE-sign connection failures — those are safe to retry.

The messaging/recovery half of ERR-00-03 otherwise behaves (honest banners, usable UI, no infinite pending) — the hazard is specifically the retry invitation plus the false "could not broadcast" claim.

Found during #337 ERR-00-03 (broadcast timeout) — build 3169af0, Cosmostation, EMBER/CORAL pair. Repro (RPC hang, not refusal — the common mainnet failure mode): - Prepared a 1 EMBER -> CORAL swap, clicked Swap, froze the chain container (sockets hang, not refuse) before approving in the wallet, then approved. - Dapp showed "Could not broadcast the transaction. Check your connection and try again." and returned to ready state. - Chain unfrozen ~2 min later: the queued broadcast flushed and the ORIGINAL tx executed clean — 36324C8CF5C65FF9C9CC33A4ABF4B647B3286DF1A5E43823AF1A0A187AB06EBE, code 0, height 1031478, the exact 1,000,000 uEMBER swap. So the failure copy is wrong about the state and actively invites a duplicate: after signing, the tx exists; "try again" within the deadline window = double-execution. The msg-level deadline does bound the window (this tx landed inside it), but it's minutes wide — plenty of time to retry. Suggested handling for broadcast failure AFTER signing: - The client can compute the tx hash from the signed bytes. Surface "broadcast status unknown — the transaction may still confirm", poll LCD /txs/{hash} through the deadline window before re-enabling submit, then resolve to success or definitively-not-found (only then offer retry). - Keep the current copy for PRE-sign connection failures — those are safe to retry. The messaging/recovery half of ERR-00-03 otherwise behaves (honest banners, usable UI, no infinite pending) — the hazard is specifically the retry invitation plus the false "could not broadcast" claim.

Rows
Columns