A trivial doubt.

[adityabhattad2021]

when we call a function of the smart contract from Javascript, when is it absolutely necessary to do it like this

const tx = await someContract.someFunction();
await tx.wait(1);

we can use this for normal getter functions also, is there any reason to not call a function like this always?

[krakxn]

1. "is there any reason to not call a function like this always" Assuming from the phrasing, what other approach do you allude to specifically?

2. "we can use this for normal getter functions also" Yeah, either someContract.someStorageVariable() or someContract.getSomeStorageVariable()

[adityabhattad2021]

I meant when await tx.wait(1); is necessary?

[adityabhattad2021]

Hey thanks for taking out your time to answer.

[krakxn]

@adityabhattad2021 Yes, it is.

Why? It is to wait for the block to be added, i.e. our transaction to be mined.

Now, the doubt arises as to the amount of blocks to wait for.

For our test environment, it is primarily our transactions, so waiting one block is sufficient for the transaction.

But for testnets and mainnets, it is not just our transactions. It is inclusive of everyone using that specific network, and there are miners mining those blocks. Also, if you have noticed, there is additionally the fact that our "contract" has to be processed to the back-end. E.g. you would have noticed Etherscan's backend does not recognize our contract unless you wait for a while.

So, it is recommended to additionally wait a few more blocks for the integration with the back-end.

[adityabhattad2021]

Thanks again!

[SatamSai]

tx.wait(1) basically means we are waiting for 1 block to be added after our transaction and code doesn't executes further until we get 1 block confirmation
Higher number of block confirmations finalize your transaction and you should wait for at least 6 blocks confirmations as mentioned in the course beginning so we use it to generate tx receipt (which can be useful for events emitted) after some blocks. But during testing we don't have much time to wait so we wait for 1 block.

Code still works if you avoid tx.wait().
But we should wait for some blocks to get mined

[krakxn]

No, that is incorrect. The transaction(s) need to be mined even on a local network, and subsequently not just a good practice but something which must be done (if there are transactions involved, which is likely of course).

For conclusive evidence, here is documentation:

Resolves to the [TransactionReceipt](https://docs.ethers.io/v5/api/providers/types/#providers-TransactionReceipt) once the transaction has been included in the chain for confirms blocks. If confirms is 0, and the transaction has not been mined, null is returned

This also acts as a precaution and returns null if it has not been mined.

Hence, it CANNOT be avoided.

[SatamSai]

Now I am getting little bit confused.
I used to run test code on Ganache chain without wait(1) statement for most of the function calls but still blocks use to get added with each block having single transaction. So I thought tx.wait only makes difference when we have to wait for more than 1 block confirmations or if we want tx receipt for event triggers and other information related to transaction.

[adityabhattad2021]

Oh, will definitely keep that in mind. Thanks @krakxn !

[krakxn]

@SatamSai Do not worry, it is not weird to think that way; Ganache is a very convenient tool, as below:

Mine blocks instantly, at interval, or on demand

Ganache allows you to configure how you want blocks to be mined during development; by default, blocks will be mined immediately upon receiving a transaction, but you can choose between the following options:

• At interval: You can specify the time in seconds Ganache should wait before mining the next transaction by passing the --miner.blockTime <TIME IN SECONDS> option. A block time of 0 means Ganache should mine new transactions instantly.

• On demand: Ganache also exposes an evm_mine RPC method which forces a single block to be mined whether mining is running or stopped. This will mine an empty block if no transaction exists in the mempool. See code sample below:

console.log("start", await provider.send("eth_blockNumber"));
await provider.send("evm_mine", [{blocks: 5}] ); // mines 5 blocks
console.log("end", await provider.send("eth_blockNumber"));

[SatamSai]

Yup got it !!