What
Emit transaction status-change events by diffing status inside #updateTransactionInternal, instead of relying on callers to manually invoke #onTransactionStatusChange (and the status-specific transactionFailed / transactionConfirmed / transactionDropped / transactionFinished publishes).
Why
Today these events are fired manually at ~8 separate call sites. That makes emitting an event a "conscious decision" the author has to remember, rather than something derived from the state, which should be the source of truth. Any code path that mutates a transaction's status without also calling the emit helpers silently skips the events.
This is exactly what caused #9400: SmartTransactionsController marked a transaction failed via the plain updateTransaction action, which doesn't emit transactionStatusUpdated / transactionFailed, so the bridge status controller was never notified and the transaction stayed stuck as pending.
#9400 fixed the symptom with a targeted failTransaction action, but the underlying fragility remains.
Proposal
Risk / notes
Not just transactionStatusUpdated — the status-specific events (transactionFailed, transactionConfirmed, transactionDropped, transactionFinished) also need to be derived from the diff, and every existing manual emit must be removed to avoid double-firing. This touches every add/approve/sign/submit/confirm/drop/fail path, so it needs careful review and test coverage. Raised as a follow-up from #9400 rather than folded into that fix.
Context: review discussion on #9400
What
Emit transaction status-change events by diffing
statusinside#updateTransactionInternal, instead of relying on callers to manually invoke#onTransactionStatusChange(and the status-specifictransactionFailed/transactionConfirmed/transactionDropped/transactionFinishedpublishes).Why
Today these events are fired manually at ~8 separate call sites. That makes emitting an event a "conscious decision" the author has to remember, rather than something derived from the state, which should be the source of truth. Any code path that mutates a transaction's
statuswithout also calling the emit helpers silently skips the events.This is exactly what caused #9400:
SmartTransactionsControllermarked a transaction failed via the plainupdateTransactionaction, which doesn't emittransactionStatusUpdated/transactionFailed, so the bridge status controller was never notified and the transaction stayed stuck as pending.#9400 fixed the symptom with a targeted
failTransactionaction, but the underlying fragility remains.Proposal
statusinside#updateTransactionInternaland publish the appropriate event(s) automatically after the update.#onTransactionStatusChangecall sites once the diff covers them.failTransactionaction (added in fix: fail cancelled smart transactions through the standard failure path #9400) can then be removed.Risk / notes
Not just
transactionStatusUpdated— the status-specific events (transactionFailed,transactionConfirmed,transactionDropped,transactionFinished) also need to be derived from the diff, and every existing manual emit must be removed to avoid double-firing. This touches every add/approve/sign/submit/confirm/drop/fail path, so it needs careful review and test coverage. Raised as a follow-up from #9400 rather than folded into that fix.Context: review discussion on #9400