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.
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?
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. :)
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 ?
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.
Weird… Thanks! I’ll use that to reproduce it. :)
I was able to reproduce it. Working on it now. :)
I’ve fixed it locally, but have a few other changes I am working on. It will go out with the next release. :)
This is fixed in 5.4.2. Let me know if you still have any issues. :)
Most helpful comment
I’ve fixed it locally, but have a few other changes I am working on. It will go out with the next release. :)