wallet.writeContract() and wallet.sendTransaction() support confirmation and reorg handling.
Confirmations
By default all transactions via wallet.writeContract() or state-changing methods on contracts will wait for one confirmation before resolving the method’s promise. This means that the transaction will be seen in at least one block by the time your task execution advances. But you can configure this further with the optional TransactionConfirmation logic. If your transaction doesn’t make it into the number of blocks specified the context function call will fail and retry logic will kick in. If it still doesn’t make it into the desired number of blocks after retries are exhausted then the promise will reject. Here’s an example for both wallet.writeContract() and on a contract class methodReorgs
Reorgs could revert your transaction after the the promise is resolved and the confirmations are all seen. For example, if you have 5 confirmations but later on a 100 block reorg occurs, you can configure your transaction with various retry “behaviors” to handle that situation. Like with confirmations, reorg handling can be used both with wallet.writeContract() as well as any state-changing methods on a smart contract class. There are several behaviors that we support currently:| behavior | description | other params |
|---|---|---|
| replay | re-executes transaction with fresh gas parameters and nonce (recalculated at replay time) | n/a |
| log | just logs the reorg to your standard app logs | logLevel (optional) |
| task | allows you to pass a compose task to call for custom handling | task (name of compose task) |
Examples
Monitored transactions are checked for reorgs every 5 minutes. When a reorg is detected and the
replay action is configured, the transaction is re-submitted with fresh gas parameters and nonce (not the original values, since the post-reorg state may differ).