Confirmations undefined on response from JsonRpcProvider.sendTransaction

[OliverNChalk]

Describe the bug
TransactionResponse declared confirmations as required when it appears to be optional. I am hitting some public MATIC mainnet nodes, so not 100% sure if this is a typing issue brought about by the differences in JsonRPC there. I am hitting ethers.providers.JsonRpcProvider.sendTransaction

Reproduction steps

            this.mSecondaryProviders.forEach((aProvider: ethers.providers.JsonRpcProvider): void =>
            {
                console.log("Sending to provider:", aProvider.connection.url);
                aProvider.sendTransaction(lSignedTransaction)
                    .then((aResponse: ethers.providers.TransactionResponse): void =>
                    {
                        console.log(aProvider.connection.url, "succeeded");
                        console.log(aResponse);
                        console.log("Confirmations:", aResponse.confirmations);
                        if (aResponse.confirmations > 0)
                        {
                            lTransactionHash = aResponse.hash;
                        }
                    })
                    .catch((aError: any): void =>
                    {
                        console.error(aProvider.connection.url, " had an error");
                    });
            });

Console output:

Sending to provider: https://rpc-mainnet.matic.network
Sending to provider: https://rpc-mainnet.maticvigil.com
Sending to provider: https://rpc-mainnet.matic.quiknode.pro
Sending to provider: https://matic-mainnet.chainstacklabs.com
Sending to provider: https://matic-mainnet-full-rpc.bwarelabs.com
Sending to provider: https://matic-mainnet-archive-rpc.bwarelabs.com
https://rpc-mainnet.maticvigil.com succeeded
{
  nonce: 170,
  gasPrice: BigNumber { _hex: '0x01a13b8600', _isBigNumber: true },
  gasLimit: BigNumber { _hex: '0x1e8480', _isBigNumber: true },
  to: 'redacted',
  value: BigNumber { _hex: '0x00', _isBigNumber: true },
  data: 'redacted',
  chainId: 137,
  v: 309,
  r: 'redacted',
  s: 'redacted',
  from: 'redacted',
  hash: 'redacted',
  type: null,
  wait: [Function (anonymous)]
}
Confirmations: undefined
https://rpc-mainnet.matic.quiknode.pro  had an error
https://matic-mainnet.chainstacklabs.com  had an error
https://rpc-mainnet.matic.network  had an error
https://matic-mainnet-archive-rpc.bwarelabs.com  had an error

Environment:
Node: v16.2
Ethers: v5.3.1

Search Terms
Often similar issues have come up before. Include any search terms you have tried in this repository's Issues (including closed issues) and "Discussions", so if there are matching issues, we can be sure to add those keywords and link this issue to it, making it easier for people to find in the future.

[zemse]

Yes the TransactionResponse.confirmations is not initialized when coming from JsonRpcProvider.sendTransaction.

@ricmoo Either we can make confirmations optional or better it can be initialized to 0 if tx is pending and 1 if just confirmed (ganache/hardhat). What do you think?

[ricmoo]

Yes, I should be initializing it to 0. I will still let that be the result even on Ganache since the updating poll will fill it in. I don't like making special exceptions, especially for test environments, but will certainly get things initialized properly in the next release. :)

[ricmoo]

Actually, I can't find any paths which result in confirmations equal to null and haven't yet been able to reproduce this... It should always be populated within the getTransaction method. Were you able not able to reproduce this @zemse ?

[zemse]

When we do wallet.sendTransaction({}), the object it doesn't include a confirmations prop.

(It appears from source code that it should work, but not sure why it is not)

Can you try to reproduce the following

> await w.sendTransaction({})
Object
chainId: 42
data: "0x"
from: "0xC8e1F3B9a0CdFceF9fFd2343B943989A22517b26"
gasLimit: e {_hex: "0xcf08", _isBigNumber: true}
gasPrice: e {_hex: "0x0147d35700", _isBigNumber: true}
hash: "0x58cb60724ffd8b00b7991df86ea913848a8fce4434bd9c9d201495ac73738acf"
nonce: 1885
r: "0x503ab8764461fc8fcfc5a8b1ba51b5adc7c90674d9039a79695999d0271c8816"
s: "0x39b322b482f42c91439a45a45113a64996661463f5414fcf2a85c6b601b3fa24"
to: null
type: null
v: 119
value: e {_hex: "0x00", _isBigNumber: true}
wait: function(t,o)
Object Prototype

It really doesnt contain confirmations for some reason. While when I manually tried getTransaction -> _wrapTransaction, it works.

[ricmoo]

Weird… Thanks! I’ll use that to reproduce it. :)

[ricmoo]

I was able to reproduce it. Working on it now. :)

[ricmoo]

I’ve fixed it locally, but have a few other changes I am working on. It will go out with the next release. :)

[ricmoo]

This is fixed in 5.4.2. Let me know if you still have any issues. :)

[ricmoo]

Closing this now, as it should be resolved. If not though, please re-open.

Thanks! :)

[fubar]

@ricmoo I'm not sure I follow this "fix". I see that the value now gets initialized to zero, but it never changes. What's the reason it doesn't get populated with the actual number of block confirmations?

(Edited to remove inaccurate comment about optional type declaration)

[fubar]

Extending on this: The TransactionResponse's wait method works as expected. However, it returns a TransactionReceipt, which does not include the block timestamp. The TransactionResponse does include a timestamp property, but it's undefined, in line with the original issue of this thread.

[ricmoo]

@fubar A confirmations of 0 indicates the block is not yet mined (once it is in a block, it has 1 confirmation). A block that has not been mined has no timestamp, because that is the time at which it was mined (according to the block header of its block).

Nearly every object in ethers is meant to be immutable. It doesn’t update the object, as the object represents a snapshot of the data at the time it was collected. You need to call the method again for a newer snapshot. Or use the .wait(confirms?) to defer querying until that number of confirms has been received.

Make sense?

[fubar]

@ricmoo got it, thanks for the explanations. What's the reason TransactionReceipt does not include a timestamp?

[ricmoo]

@fubar It isn’t part of the official response API of the JSON-RPC, which a lot of the ethers porcelain API was originally modelled after. Deviating would incur additional costs, since I would have to call getTransacrion on every request for a receipt.

Why isn’t it included there? My guess is that in Geth it would have meant another leveldb lookup against the disk, so they decided. It to, but I don’t know for certain. Just a guess. :)

[fubar]

@ricmoo I see, makes sense. Cheers!