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

ricmoo · 2021-04-16T06:36:03Z

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.

The text was updated successfully, but these errors were encountered:

ricmoo · 2021-05-20T21:55:30Z

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

…io#1477).

mwamedacen · 2021-06-05T15:24:02Z

Thanks you @ricmoo, exciting feature out here and very much need !

Any plan to support it for external providers (through Web3Provider)?

Indeed, current implementation of JsonRpcSigner#sendTransaction doesn't pass startBlock

    return this.provider._wrapTransaction(tx, hash);

which results in replacement always being undefined in BaseProvider#wrapTransaction

    if (confirms !== 0 &amp;&amp; startBlock != null) {
        replacement = {

which ultimately results into opting out of tx replacement watching in BaseProvider#_waitForTransaction

    if (replaceable) {
        let lastBlockNumber = replaceable.startBlock;

I can think of multiple of solutions (calling _getInternalBlockNumber in JsonRpcSigner#sendTransaction, pass blockNumber to _wrapTransaction in BaseProvider#getTransaction...) but I'm not sure of the potential side effects or if these are ubiquitous enough.

Would love to hear from you back.

ricmoo · 2021-06-07T19:30:00Z

@mwamedacen Thanks! Yes, it was completely an oversight. I will add that to the next release. :)

mwamedacen · 2021-06-22T07:44:01Z

Thanks again @ricmoo, do you think it would be possible to opt-in for transaction replacement detection through BaseProvider#waitForTransaction() ? Thank you

ricmoo · 2021-06-22T07:49:48Z

@mwamedacen What do you mean? You want to not throw on replacement and receive no notice and stall indefinitely?

You can just use const receipt = await tx.wait().catch(() => new Promise((r)=>{}) to discard any replacement and stall the program from every progressing in that block. If the transaction works, once mined the receipt is set and moves forward. If the transaction is replaced the code will never progress past that line.

mwamedacen · 2021-06-22T07:59:16Z

@mwamedacen What do you mean? You want to not throw on replacement and receive no notice and stall indefinitely?

You can just use const receipt = await tx.wait().catch(() => new Promise((r)=>{}) to discard any replacement and stall the program from every progressing in that block. If the transaction works, once mined the receipt is set and moves forward. If the transaction is replaced the code will never progress past that line.

Sorry I wasn't clear, I meant: if we deal with transaction hash, waiting for transaction never throws on replacement (might be wrong though).

ricmoo · 2021-06-22T08:04:24Z

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?

mwamedacen · 2021-06-23T13:13:09Z

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);
    }

devdomsos · 2022-02-21T18:49:26Z

Hey Ricmoo, @ricmoo

thanks for an amazing support for the speeded-up transaction.

I am right now testing the functionality on Polygon. Maybe I am doing sth wrong but I have followed your explanation here:
https://blog.ricmoo.com/highlights-ethers-js-may-2021-2826e858277d

Updated the version of ethers.js to 5.5.4 to have the support for replaced transactions.

I have the following pattern:

I have a handleDepositCallback function that calls the contract. That function returns response object that has the wait method. Then on the front-end, I have the following

const handleModalConfirm = useCallback(async () => {
   
    if (handleDepositCallback) {
      const tx = await handleDepositCallback()
      try {
        // Wait for the transaction to be mined
        const hashish = await tx?.hash

        console.debug('deposited', { hashish })
        onSetDepositHash(hashish, sourceChainId)

        const result = await tx?.wait();
     
        return result

      } catch (error) {

        console.debug(error, 'error in the first catch wait await')

        if (error.code === Logger.errors.TRANSACTION_REPLACED) {
          if (error.cancelled) {
            // The transaction was replaced  :'(
            console.debug(error.replacement, 'The transaction was replaced  ')
        
          } else {
            // The user used "speed up" or something similar
            // in their client, but we now have the updated info
            console.debug(error.replacement, 'error.replacement');
            console.debug(error.receipt, 'error.receipt')
         
          }
        }
      }

Then using MetaMask, I submit a transaction:

First transaction goes with Low gas fee
After a second or 2 I use MM feature to speed up the transaction using custom fee.
the first transaction does not go through : https://polygonscan.com/tx/0x0b52f9b3c1e25916ea23b86118266dccfbc30dddaa2fbcc0d8fed1c7eecd9182
the 2nd gets mined: https://polygonscan.com/tx/0xd673066a971ed4b383d6ef88b19fc8e017ce6568809877d60e4629b6f5c4f196

In such case, should we get to the catch() block?

ricmoo · 2022-02-21T18:51:45Z

Yes, you should get the catch block. Are you not?

devdomsos · 2022-02-21T18:56:27Z

No, it never gets to the } catch (error) {. I have tested it with a single transaction (not speeded-up), and the code properly goes to:

const result = await tx?.wait();

and returns the transaction details with receipt.

It could be that I am doing sth wrong, therefore I prefer to check with you.

I have only tested it on Polygon. I will try also on BSC.

ricmoo · 2022-02-21T19:01:31Z

There are definitely problems with both Polygon and BSC when it comes to receipts, that are still being tracked down; they seem to emit data before they complete indexing (and therefore responding to requests).

So, the result.transactionHash != tx.hash? Are either left undefined? Do the nonce and from match?

Velenir · 2022-02-21T19:12:08Z

When submitting a low-priced transaction on Polygon I often encounter that resulting TransactionResponse.from === "0x000... , zero address. Polygonscan shows the same zero address.

In that case replacement tx won't be detected.
In my experience this issue only happens with public rpc, private nodes are more reliable.

@devdomsos may this be your issue?

devdomsos · 2022-02-21T19:33:46Z

There are definitely problems with both Polygon and BSC when it comes to receipts, that are still being tracked down; they seem to emit data before they complete indexing (and therefore responding to requests).

So, the result.transactionHash != tx.hash? Are either left undefined? Do the nonce and from match?

Yes, result.transactionHash != tx.hash
In both cases hashes are defined. The hash is generated immediately for both txs (not mined and mined).
But if I try to resolve a promise from an un-mined transactions hash (so the first transaction) I get undefined.
Do the nonce and from match? --> I have the problem with nonce and from. On Polygon, so far I have been getting the mined transaction via polygonscan API. There I get an object like this:

{
blockNumber: '25056381', 
timeStamp: '1645120639', 
hash: '0x80ba412a261313a74b96a93c16a529c6b625c2942343464da354d436a1c49e3b', 
nonce: '122', 
blockHash: '0xc47eb987ac11b076962a85f840cd09352c5de30f7e221baed37167b52388e712', …}
blockHash: "0xc47eb987ac11b076962a85f840cd09352c5de30f7e221baed37167b52388e712"
blockNumber: "25056381"
confirmations: "21873"
contractAddress: ""
cumulativeGasUsed: "10154133"
from: "0xc33c31ff0b6c13c643b80d6c63c8a44e507dd273"
gas: "105644"
gasPrice: "34578977251"
gasUsed: "90014"
hash:"0x80ba412a261313a74b96a93c16a529c6b625c2942343464da354d436a1c49e3b"
input: "0x178a8a9800000000000000000000000092868a5255c628da08f550a858a802f5351c522300000000000000000000000000000000000000000000000000005af3107a4000000000000000000000000000c33c31ff0b6c13c643b80d6c63c8a44e507dd2730000000000000000000000000000000000000000000000000000000000000038"isError: "0"
nonce: "122"
timeStamp: "1645120639"
to: "0xcbce172d7af2616804ab5b2494102daec47b2635"
transactionIndex: "36"
txreceipt_status: "1"
value: "0"[[Prototype]]:
}

That is a mined transaction.

The not-mined transaction object looks like this:

{hash: '0x773c58c16ce4be464fae08a266910e54919824d7bd49903094f5a28360321f07',
chainId: null 
data: null 
from: null 
gasLimit: null 
gasPrice: null 
hash: "0x773c58c16ce4be464fae08a266910e54919824d7bd49903094f5a28360321f07" 
nonce: null 
value: null 
wait: confirmations => {…}
}

As you can see both nonce and from are null from the 1st (not-mined) tx.
And so I cannot compare nonce and from of the 1st transactionObject and then the 2nd (final) transactionObject that I get from polygonscan API.

@Velenir, I have null for the 'from' key on Polygon. I have tried 2 RPC urls, both were public. Which nodes would you recommend I use?

Velenir · 2022-02-22T06:57:47Z

Which nodes would you recommend I use?

I had good results with Infura, quicknode is another good candidate

devdomsos · 2022-02-22T09:26:19Z

@Velenir thank you. I will have to use these then.

@Velenir However, I would be interested in the following: is the new support for replaced transactions provided by ethers library working for you?

Velenir · 2022-02-22T11:35:37Z

However, I would be interested in the following: is the new support for replaced transactions provided by ethers library working for you?

Yes, all in all it's working. Not working only in the case of:

On polygon with public rpc
And I purposefully send a low-priced transaction

devdomsos · 2022-02-23T10:49:33Z

However, I would be interested in the following: is the new support for replaced transactions provided by ethers library working for you?

Yes, all in all it's working. Not working only in the case of:

On polygon with public rpc

And I purposefully send a low-priced transaction

@Velenir thank you for the info. How would you recommend I test then the transaction replacement on Polygon? I would then have to wait for the network to be congested to test this? On BSC I am not even able to in time upspeed the transaction. It goes through right away.

Velenir · 2022-02-23T11:50:01Z

How would you recommend I test then the transaction replacement on Polygon?

If you use a private node, then you should be able to send an intentionally underpriced transaction and it would be detected alright.
If you use a public rpc, you need to be fast and get lucky.

devdomsos · 2022-02-23T12:45:22Z

How would you recommend I test then the transaction replacement on Polygon?

If you use a private node, then you should be able to send an intentionally underpriced transaction and it would be detected alright. If you use a public rpc, you need to be fast and get lucky.

For POLYGON
I changed the node to a private one from Infura for Polygon - getting the same result as with using public rpc. Meaning I never get to the catch block.

For BSC
Well, then it is what it is. :D

Could you share with us the way you call the smart contract and how you await for the wait() promise? Only if you are ok with sharing this of course. Maybe I am doing something wrong on my end.

GregTheGreek · 2022-02-24T17:12:10Z

Can we standardize this as EIP-2831?

aysuio · 2022-03-03T23:16:44Z

Hey @devdomsos, thanks for the sample code. I'm using typescript and struggling to handle the error from tx.wait(). Is there way to assign error message type to the error so that I know what I'm dealing with during coding? Here is an example：

 try{
  await txResp.wait(1)
} catch ( error: CertainErrorType ) {
  // do sth
}

What the "CertainErrorType " should be?

devdomsos · 2022-03-11T16:38:22Z

@aysuio, not sure if you found an answer to it, but generally I was using template code from this update:
https://blog.ricmoo.com/highlights-ethers-js-may-2021-2826e858277d

 } catch (error) {

        console.debug(error, 'error in the first catch wait await')

        if (error.code === Logger.errors.TRANSACTION_REPLACED) {
          if (error.cancelled) {
            // The transaction was replaced  :'(
            console.debug(error.replacement, 'The transaction was replaced  ')
        
          } else {
            // The user used "speed up" or something similar
            // in their client, but we now have the updated info
            console.debug(error.replacement, 'error.replacement');
            console.debug(error.receipt, 'error.receipt')
         
          }
        }

Let me know if you managed to test this feature on your end. :) I still cannot get it to work because I cannot test it.

aysuio · 2022-03-29T22:01:23Z

@aysuio, not sure if you found an answer to it, but generally I was using template code from this update: https://blog.ricmoo.com/highlights-ethers-js-may-2021-2826e858277d
 } catch (error) {

        console.debug(error, 'error in the first catch wait await')

        if (error.code === Logger.errors.TRANSACTION_REPLACED) {
          if (error.cancelled) {
            // The transaction was replaced  :'(
            console.debug(error.replacement, 'The transaction was replaced  ')
        
          } else {
            // The user used "speed up" or something similar
            // in their client, but we now have the updated info
            console.debug(error.replacement, 'error.replacement');
            console.debug(error.receipt, 'error.receipt')
         
          }
        }
Let me know if you managed to test this feature on your end. :) I still cannot get it to work because I cannot test it.

tried TRANSACTION_REPLACED, it generated error params as stated in ethers.js enum ErrorCode

There are bunch of other codes like UNPREDICTABLE_GAS_LIMIT, which are well defined in the ErrorCode.

devdomsos · 2022-04-19T11:15:06Z

@aysuio, not sure if you found an answer to it, but generally I was using template code from this update: https://blog.ricmoo.com/highlights-ethers-js-may-2021-2826e858277d
 } catch (error) {

        console.debug(error, 'error in the first catch wait await')

        if (error.code === Logger.errors.TRANSACTION_REPLACED) {
          if (error.cancelled) {
            // The transaction was replaced  :'(
            console.debug(error.replacement, 'The transaction was replaced  ')
        
          } else {
            // The user used "speed up" or something similar
            // in their client, but we now have the updated info
            console.debug(error.replacement, 'error.replacement');
            console.debug(error.receipt, 'error.receipt')
         
          }
        }
Let me know if you managed to test this feature on your end. :) I still cannot get it to work because I cannot test it.
tried TRANSACTION_REPLACED, it generated error params as stated in ethers.js enum ErrorCode

There are bunch of other codes like UNPREDICTABLE_GAS_LIMIT, which are well defined in the ErrorCode.

@aysuio, how did you manage to re-produce the replaced transaction? Which blockchain were you testing it on? Thanks!

tiff0000 · 2022-11-02T05:02:31Z

When you get TRANSACTION_REPLACED, how can you get the new transaction hash that of the replacement?

ricmoo · 2022-11-02T06:11:12Z

@tiff0000

The replacement property on the error has the entire tx including the hash. See https://docs.ethers.io/v5/api/utils/logger/#errors--transaction-replaced . :)

GregTheGreek · 2022-11-02T19:48:04Z

@ricmoo Is ethers just polling the node under the hood to grab all the information?

ricmoo · 2022-11-02T20:04:16Z

@GregTheGreek Depending on the backend, it uses the block listener to then get the nonce; if the nonce has changed, then it searches the block for the tx matching the nonce and from, to derive the replacement reason (replaced, cancelled or repriced).

bilaljawed · 2023-07-27T08:47:43Z

@ricmoo Question:

I dont have a TransactionReceipt object as i am getting the hash from metamask from frontend to backend, If i go another way by passing transaction hash to waitForTransaction(hash) is it going to act the same way as tx.wait() ?

Thanks

ricmoo added enhancement New feature or improvement. on-deck This Enhancement or Bug is currently being worked on. minor-bump Planned for the next minor version bump. labels Apr 16, 2021

ricmoo mentioned this issue Apr 27, 2021

How get new hash trx after spead-up #1520

Closed

ricmoo added a commit that referenced this issue May 14, 2021

Added new error for replaced transactions (#1477).

987bec8

ricmoo added a commit that referenced this issue May 14, 2021

Added initial support for detecting replacement transactions (#1477).

5144acf

ricmoo added fixed/complete This Bug is fixed or Enhancement is complete and published. and removed on-deck This Enhancement or Bug is currently being worked on. labels May 20, 2021

ricmoo closed this as completed May 30, 2021

pull bot pushed a commit to shapeshift/ethers.js that referenced this issue Jun 4, 2021

Added new error for replaced transactions (ethers-io#1477).

16f2cb5

pull bot pushed a commit to shapeshift/ethers.js that referenced this issue Jun 4, 2021

Added initial support for detecting replacement transactions (ethers-…

a1b5f7b

…io#1477).

pull bot pushed a commit to shapeshift/ethers.js that referenced this issue Jun 4, 2021

Added new error for replaced transactions (ethers-io#1477).

b05c588

pull bot pushed a commit to shapeshift/ethers.js that referenced this issue Jun 4, 2021

Added initial support for detecting replacement transactions (ethers-…

5e861a6

…io#1477).

mwamedacen mentioned this issue Jun 7, 2021

Extend support of transaction replacement detection to JsonRPCProviders #1658

Closed

danielattilasimon mentioned this issue Jun 11, 2021

Dev UI doesn't recognize when sped-up transactions get mined liquity/dev#601

Closed

htadashi mentioned this issue Feb 23, 2022

EIP-2831 Transaction Replacement Message Type ethereum/EIPs#2831

Merged

duyphanz mentioned this issue Jun 30, 2022

Can't catch when a speed up transaction is confirmed icon-project/Nexus#626

Closed

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

ricmoo commented Apr 16, 2021

ricmoo commented May 20, 2021

mwamedacen commented Jun 5, 2021 •

edited

ricmoo commented Jun 7, 2021

mwamedacen commented Jun 22, 2021

ricmoo commented Jun 22, 2021

mwamedacen commented Jun 22, 2021

ricmoo commented Jun 22, 2021

mwamedacen commented Jun 23, 2021

devdomsos commented Feb 21, 2022 •

edited

ricmoo commented Feb 21, 2022

devdomsos commented Feb 21, 2022 •

edited

ricmoo commented Feb 21, 2022

Velenir commented Feb 21, 2022

devdomsos commented Feb 21, 2022 •

edited

Velenir commented Feb 22, 2022

devdomsos commented Feb 22, 2022

Velenir commented Feb 22, 2022

devdomsos commented Feb 23, 2022

Velenir commented Feb 23, 2022

devdomsos commented Feb 23, 2022 •

edited

GregTheGreek commented Feb 24, 2022

aysuio commented Mar 3, 2022 •

edited

devdomsos commented Mar 11, 2022 •

edited

aysuio commented Mar 29, 2022 •

edited

devdomsos commented Apr 19, 2022

tiff0000 commented Nov 2, 2022

ricmoo commented Nov 2, 2022

GregTheGreek commented Nov 2, 2022 •

edited

ricmoo commented Nov 2, 2022

bilaljawed commented Jul 27, 2023

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

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

Comments

ricmoo commented Apr 16, 2021

ricmoo commented May 20, 2021

mwamedacen commented Jun 5, 2021 • edited

ricmoo commented Jun 7, 2021

mwamedacen commented Jun 22, 2021

ricmoo commented Jun 22, 2021

mwamedacen commented Jun 22, 2021

ricmoo commented Jun 22, 2021

mwamedacen commented Jun 23, 2021

devdomsos commented Feb 21, 2022 • edited

ricmoo commented Feb 21, 2022

devdomsos commented Feb 21, 2022 • edited

ricmoo commented Feb 21, 2022

Velenir commented Feb 21, 2022

devdomsos commented Feb 21, 2022 • edited

Velenir commented Feb 22, 2022

devdomsos commented Feb 22, 2022

Velenir commented Feb 22, 2022

devdomsos commented Feb 23, 2022

Velenir commented Feb 23, 2022

devdomsos commented Feb 23, 2022 • edited

GregTheGreek commented Feb 24, 2022

aysuio commented Mar 3, 2022 • edited

devdomsos commented Mar 11, 2022 • edited

aysuio commented Mar 29, 2022 • edited

devdomsos commented Apr 19, 2022

tiff0000 commented Nov 2, 2022

ricmoo commented Nov 2, 2022

GregTheGreek commented Nov 2, 2022 • edited

ricmoo commented Nov 2, 2022

bilaljawed commented Jul 27, 2023

mwamedacen commented Jun 5, 2021 •

edited

devdomsos commented Feb 21, 2022 •

edited

devdomsos commented Feb 21, 2022 •

edited

devdomsos commented Feb 21, 2022 •

edited

devdomsos commented Feb 23, 2022 •

edited

aysuio commented Mar 3, 2022 •

edited

devdomsos commented Mar 11, 2022 •

edited

aysuio commented Mar 29, 2022 •

edited

GregTheGreek commented Nov 2, 2022 •

edited