Timeout creating transaction via contract method

[cliffhall]

The scenario, running in a Node service, is essentially this:

    // Create contract with signer (works fine, nothing to see here)
    const provider = new ethers.getDefaultProvider(NETWORK);
    const wallet = new ethers.Wallet(account.privateKey, provider);
    const contract = new ethers.Contract(contractAddress, ABI, provider);
    const contractWithSigner = contract.connect(wallet);
    
    // Options for the transaction (works fine, nothing to see here)
    const options = {
        gasLimit: FIXED_GAS,
        gasPrice: ethers.utils.parseUnits(gasPriceInGwei, 'gwei')
    };

    // Call contract method (this is the sticky wicket)
    try {
       console.log(`${id} minting at gas price ${price}`);
       const tx = await contractWithSigner.myFunction(arg, options);  // HANGS HERE
       console.log(tx.hash);  // This never happens. 
       await tx.wait().then( // Nor does this...
                () => {
                    console.log(`${id} tx confirmed via ethers ${tx.hash}`);
                    success();
                },
                e => {
                    console.log(`${id} tx failed via ethers ${tx.hash}`);
                    failure(e);
                }
       );
   } catch (e) {
      failure(e) // This gets executed when process times out in ~30 minutes
   }

This works the bulk of the time, and everything's rosey. But often enough it hangs trying to create the transaction, and that holds up the entire works in my app.

I need a way to tell this thing to give up or fail over sooner. I'm not certain how it goes about getting the transaction out the door, if it tries Infura first, then gives up and uses Etherscan after 15 minutes or what, but it can take 30 minutes to timeout.

In the log screenshot above, the process logs that it's 'minting at gas price x', then the catch clause of the try/catch has been invoked, logging the 'tx end updated' message and finally the error message, which was 'timeout', about 30 minutes after the attempt to call the contract function.

How can I get this under control? I see no options for setting a timeout on the contract call itself.

[ricmoo]

What network are you using? Can you pass along the contract, gas price, gas limit, etc. you are using? Can you also do a console.log(provider.providerConfigs); on the default provider? It should be a list of the backends it is using.

The default provider on sendTransaciton will execute them all immediately and simultaneously, so as long as any one of them works, it should be peachy...

[cliffhall]

Network: 'rinkeby'.
Contract: Avastars PrimeMinter
Gas Limit: 600000
Gas price: Varies, I always use either the "fastest" setting returned by: etherchain's gas price oracle OR 10 gwei, should that endpoint be down. Generally in the 10 to 25 gwei range. The current one that's hung was using 10 gwei.

console.log(provider.providerConfigs); shows undefined. I'm guessing providerConfigs was a typo, since a search on the ethers.js repo returns nothing. Same goes for a search of the documentation. Did you mean some other property?

Since i'm just doing const provider = new ethers.getDefaultProvider('rinkeby'); as the documentation suggests, I assumed it had the underlying fallback stuff sorted. Is there some other configuration I'm supposed to give it?

ethers . getDefaultProvider( [ network = “homestead” ] ) => Provider
This creates a FallbackProvider backed by multiple backends (INFURA and Etherscan).
This is the recommended method of connecting to the Ethereum network if you are not running your own Ethereum node.

See the transactions at in the above contract link. When they make it out the door, which is often, they succeed (except when I am testing things that should trigger a revert).

For instance, I just ran 224 sequential transactions all the same except the from address which is randomly pulled from a pool of adequately funded (I checked) accounts, and the actual contract arguments, which are all valid. If they weren't and that was the cause, I would see a reverted transaction in the log. I don't. The address it was coming from didn't send one, and the contract never received one.

The default provider on sendTransaciton will execute them all immediately and simultaneously, so as long as any one of them works, it should be peachy...

I'm not using sendTransaction, as you can see above, I'm using the contractWithSigner.myMethod() approach to sending a transaction. If you mean it uses sendTransaciton internally, then based on this statement, I gather the hung one must have happened at a moment when both networks were temporarily unavailable? In that case, what is the retry policy, and when does it give up? And how can I control when it gives up, because by itself that seems to take about 30 minutes (see log in original post).

[Marijus]

@cliffhall I'm having the same issue - did you manage to fix yours?

[cliffhall]

@Marijus I never got it sorted. It remained the case that sometimes it just fails. I built the system around it to timeout and retry after a reasonable period.

[ccostel]

I am having a very similar issue on Binance Smart Chain Mainnet. Sometimes ethers can hang on a state changing transaction and sometimes on a call as simple as decimals() on WBNB contract.

What would be a way to debug if this is an ethers.js issue or a network/provider issue?

[ricmoo]

Yes, internally all transactions must occur over sendTransaction. Method calls just handle the binary coding for you. There should be no difference between a method call and sendTransaction at the end of the day.

If the network is unavailable, then it should fail immediately and retry.

Which backend are you using? INFURA? Are you using your own api keys? It sounds like a backend has hung up on you, but without closing its half of the pipe. This could also be a proxy issue, if you are using a proxy or load balancer. If you use a FallbackProvider for sending transactions, it will multicast your transaction on all of them and return the moment any one of them accepts it, which probably something that would help you as you can use your own node and publicly available backends to make sure your transaction gets to the network and things keep on trucking. :)

(moving to discussions)