How to bypass the pre-flight checks when sending a tx?

[PaulRBerg]

In my dapp, I have the following flow:

1. Create an empty transaction array.
2. Check if the ERC-20 allowance is sufficient and, if not, append a token approval tx to the array.
3. Append the token deposit transaction to the array.

In all cases, the array ends up having either one or two transactions inside. In the latter case, when the allowance is not sufficient, the second transaction cannot be sent because of this error thrown by ethers:

"execution reverted: SafeERC20: low-level call failed"

Now, I know what causes this. I am not waiting for the approval transaction to go through, so the state of the blockchain assumes that the allowance is not sufficient and reverts when attempting to call the "transferFrom" function.

I want to bypass this check. Basically, I want to optimistically assume that the approval transaction will go through, and that nothing else will cause the deposit transaction to revert.

One way to do it is wrap the contract call in a try/ catch block, but that would mean I have to check the error string, so that when the error is different from the one quoted above, the user is alerted about it. Is there a more elegant way to do this in ethers? Maybe there is an option that I can turn on and disable the "would this transaction revert" check?

Note: I am using Infura as the provider.

[PaulRBerg]

Nevermind, this is a duplicate of #903.

The solution was to pass a hardcoded "gasLimit" to the contract call.

[PaulRBerg]

Update: passing a hardcoded gas limit no longer disables the pre-flight checks now. I'm getting an "Internal JSON-RPC error" error even if with a specific gas limit.

@ricmoo - do you know of any recent change in geth or on Infura that could have affected this behavior?

Also, is there some sort of flag we could pass to disable the pre-flight checks?

[ricmoo]

A transaction absolutely requires a gasLimit, otherwise it won’t be able to determine whether the account meets the intrinsic cost. If you omit the gasLimit, ethers fills it in for you, based on asking the node to estimate it. So there isn’t a flag to skip that as it is required; including your own gasLimit let’s ethers know you already figured it out and not to estimate.

That error is likely unrelated to the gasLjmit though. I have seen it before, but usually when the node is having issues or non-sense (of some sort) is being passed through. You can add provider.on("debug", …) to print out more details.

Let me know what you find. :)