Best practice for retrying requests?

[nambrot]

I'm wondering what the community's best practice is for retrying requests. One thing that seems to happen sometimes is that let's say in a deployment script, tx A deploys a contract and then tx B calls a function on said contract, and even if you await them serially, depending on the reliability of your provider's RPC, when ethers estimates gas for tx B, the node may not have the block of where tx A was mined, and thus estimation of gas fails. In that gas, a simple retry should do the job, but I would like that ideally to be handled at the ethers provider level.

I see that there was a RetryProvider that was removed in 201e5ce, so I'm wondering what the best practice is now?

[zemse]

If contract deployment waits for the deploy tx to be confirmed, then it should not be a problem. But if the rpc uses a load balancer internally, and some requests can hit a node that does not have the latest block, it can be difficult to know if the revert is due to the estimation done without the latest block.

One easy thing can be specifying the gasLimit, it should be fine if the gas required for deployment does not change (or at least won't go beyond the hardcoded gas limit). However, different chains can have different scales of gas, e.g. on Arbitrum it's quiet different so hardcoding might not work for all chains or would just need to specify gasLimits for multiple chains.

[nambrot]

Yeah as we are building tooling for developers, we cannot assume nor want to prescribe specifying manual gasLimits. It obviously seems not very elegant as well.

Totally hear you that it is difficult to know whether a revert is due to inconsistent RPC nodes, but at least in our testing we have found that to be often the case. Which is why I posted in the first place, a retry generally seems quite safe but I have been surprised by the lack of prescription for retrying in ethers, nor even a recommendation as to how to do it. Resurrecting the RetryProvider from a previous commit seems so odd that I wonder if it was removed intentionally?

[zemse]

I was thinking about this, and I think one way is waiting until the contract's bytecode is non-empty.

async function waitForContract(provider, contract) {
  return new Promise(res => {
    provider.on('block', () => {
       if(await provider.getCode(contract.address) !== null) res();
    })
  })
}

Once it's non-empty it should work. But I think a problem is still there. If there are two nodes behind the load balancer, one is synced while other is caching up. If it happens that the getCode request is served by updated node while the following estimateGas request hits the other one and fails. A solution I can think of is, sending batch rpc requests, one can be eth_blockNumber and the other can be estimateGas. I hope the load balancer won't have this implemented to destructure the batch, send to the nodes and restructure the batch and respond to the client. In that case we'd know the block number of the node who is serving the estimation.

[nambrot]

I appreciate the thought here but again I'd be looking for retrying rpc calls that have arbitrary dependencies on state transitions of previous transactions. And if I understand ethers correctly using something like a retry provider is the way to go? But again idk why it was removed

[kasparkallas]

If I may ask, did you figure something out or have any pointers? :) @nambrot

I've got a dApp, with thousands of users, everyone with their own specific browsers and wallets and internet connections, and my logs riddled with CALL_EXCEPTION and SERVER_ERROR type errors that I can't reproduce and I'm not exactly sure what they're about.

missing revert data in call exception; Transaction reverted without a reason string <-- Not very helpful.

My hope is that a lot of them could be solved by a simple retry...

I explicitly retry in some places but would prefer a drop-in Provider solution.

[ricmoo]

If you use v6, it is better at extracting as much about errors as possible, but it can only work with what the contract returns; if the contract doesn’t return any more details about the error, there isn’t much ethers can do about it. :)