waitForTransactionReceipt does not work as expected
Check existing issues
- [x] I checked there isn't already an issue for the bug I encountered.
Viem Version
2.34.0
Current Behavior
The waitForTransactionReceipt function does not handle the scenario where a transaction is no longer found on the network (e.g., because it was replaced by a newer one with the same nonce and a higher gas price, or it was simply dropped from the mempool). Instead of rejecting the promise with a clear error
First Issue: The function cannot find transactions that have been replaced or dropped Second Issue: Regardless of the configuration (e.g., timeout, retryCount), the function's promise never settles (neither resolves nor rejects) if it cannot locate the transaction hash on the blockchain
Expected Behavior
waitForTransactionReceipt should detect replaced transactions or throw an error
Steps To Reproduce
This app has two buttons:
- Send 1 wei to yourself — submits a self-transfer with intentionally tiny EIP-1559 fees so it stays pending.
- Speed Up — resubmits the same nonce with higher fees, replacing the first transaction.
How to reproduce
-
Click Send 1 wei to yourself.
- The tx uses
maxFeePerGas = 2andmaxPriorityFeePerGas = 1(wei), so it will not get mined on Sepolia. It remains pending indefinitely. waitForTransactionReceiptfor this tx never resolves with a receipt (by design), because the transaction won’t be included in a block.
- The tx uses
-
After a short wait, click Speed Up.
- The app sends a replacement tx with the same nonce and higher fees (roughly
2×the currentestimateFeesPerGasvalues). - This replacement supersedes the first tx. You’ll see a receipt in the console only for the second (speed-up) transaction.
- The original tx will never produce a receipt, because it was replaced before inclusion.
- The app sends a replacement tx with the same nonce and higher fees (roughly
-
If you don’t click Speed Up, nothing will happen: the first tx stays pending forever and no receipt is printed.
https://github.com/user-attachments/assets/3452c1fc-abac-4226-b928-b18f9c7985df
Link to Minimal Reproducible Example
https://github.com/Pasha8914/waitForTransactionReceipt-bug
Anything else?
No response
I cannot reproduce this issue. Can you please break this test I made for this issue, or our existing replacement tests?
I cannot reproduce this issue. Can you please break this test I made for this issue, or our existing replacement tests?
please run my test I've managed to narrow down the problem more precisely
The issue is that during a gas spike, my transaction is rejected from the mempool. Therefore, when I try to speed it up, there is no original transaction to replace, and I do not receive a new transaction hash
@jxom
I will look into it. Please feel free to raise a PR to fix in the meantime.
just to clarify, there is a difference between replace and repriced
just to clarify, there is a difference between replace and repriced
repriced = a special case of replace, where the data is identical and only the gas/fee is changed
Why highlight repriced separately in this case? What exactly did you mean by your message?
@sambacha