question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Enable EIP- 2831 Signer transaction.wait() style rejections.

See original GitHub issue

When a Signer sends a transaction, the TransactionResponse object has a .wait() method. Currently that method rejects a CALL_EXCEPTION if the transaction reverts, otherwise it resolves with the TransactionReceipt, once the transaction is mined, based on its hash.

This feature will enable an additional rejection case, along with a new error in the Logger, TRANSACTION_REPLACED. This will occur if the transaction is replaced (i.e. the from and nonce match the transaction but the hash is different), with a field indicating the reason for the replacement:

  • repriced; the data and to match, but the gas price has changed
  • cancelled; the data has been changed to 0x and the to changed to the from
  • replaced; any other change

This must occur in a minor version bump.

In v6 we may change repriced to also resolve (instead of reject), but this requires more thought and would not be backwards compatible within v5.

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Reactions:17
  • Comments:29 (8 by maintainers)

github_iconTop GitHub Comments

3reactions
ricmoocommented, May 20, 2021

This is now available in 5.2.0. Please check out this article for more details. 😃

2reactions
mwamedacencommented, Jun 23, 2021

If you wait on a transaction hash it will eventually resolve to the receipt or throw an exception which includes the receipt of the replacement transaction. tx.wait() will eventually finish, one way or the other.

Prior to this feature, tx.wait() would never proceed if the transaction was replaced. If you want to replicate this functionality, you can use the above .catch(), but there are probably very few cases you would want to do that.

Does that make sense?

Sorry I’m a bit confused, my case is when I don’t have access to the transactionResponse object but only the hash.

So I’m waiting on the transaction via the provider, say

await web3Provider.waitForTransaction(transactionHash)

In this case, replaceable param is always passed down to _waitFortransaction() as null

    async waitForTransaction(transactionHash: string, confirmations?: number, timeout?: number): Promise<TransactionReceipt> {
        return this._waitForTransaction(transactionHash, (confirmations == null) ? 1: confirmations, timeout || 0, null);
    }
Read more comments on GitHub >

github_iconTop Results From Across the Web

Speeded up transactions via MetaMask, new tx hash tx.wait ...
Enable EIP - 2831 Signer transaction.wait() style rejections. ... sends a transaction, the TransactionResponse object has a .wait() method.
Read more >
EIP-2831: Transaction Replacement Message Type
This EIP formalizes a way for both providers and dapp developers to track transaction replacements seamlessly.
Read more >
Documentation - Ethers.js
A Signer is a class which (usually) in some way directly or indirectly has access to a private key, which can sign messages...
Read more >
EIP-2831: Transaction Replacement Message Type
I just created "EIP-2831 Transaction Replacement Message Type" This is a first attempt at solving a fundamental disconnect between providers ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found