Handle error state for generating transactions correctly#69
Handle error state for generating transactions correctly#690xnullifier wants to merge 3 commits intomainfrom
Conversation
|
Is the intent to silently continue after a single transaction failure? Users won't see any error indication until all transactions finish. |
| } | ||
|
|
||
| mutateTx(); | ||
| await mutateTx(); |
There was a problem hiding this comment.
Is this intentional? It now blocks until the cache is updated before potentially retrying.
| transactions.length === 0 | ||
| ) { | ||
| new Promise(res => setTimeout(res, 10_000)).then(async () => { | ||
| new Promise(res => (timeOutRef.current = setTimeout(res, 10_000))).then(async () => { |
There was a problem hiding this comment.
Should this also check for error state?
I tested this with the consuming note which handles the error state correctly for other than that I think dapps which send custom transaction will show if transaction fails but we can incorporate something into the UI too. Like a continue other transactions button |
|
Closing as superseded by #193, which rewrote GeneratingTransaction.tsx with a per-stage progress model. The error-gating bug this PR fixed (error icon showing before transactionComplete) no longer applies — the component now uses hasErrors + failedCount driven by getFailedTransactions() polling and correctly gates the failure icon on transactionComplete && hasErrors. The MAX_WAIT_BEFORE_CANCEL change is also no longer relevant: main now has a mobile/desktop split (2min / 30min) in seconds rather than ms. |
2 participants
No description provided.