How to get a gas fee estimation for transactions that are expected to fail

TypeScript SDK
1

Is there a way to estimate transaction fees for transactions that are expected to fail? In typescript, the provider.getTransactionCost function will fail with an error, although it’s still possible to send the transaction and pay fees for it

2

Hey @mpoplavkov, are you looking for these? Also, do you mean estimating gas fees that are bound to fail intentionally?

3

We’re using provider.getTransactionCost from typescript and it fails with an exception when trying to estimate fees of transactions that fail during simulation.

Also, do you mean estimating gas fees that are bound to fail intentionally?

Since I’m able to send any transaction on Fuel (even the one that’s expected to fail), I want to have an estimation on how expensive it would be to send it

As a wallet, we’re performing a simulation of transactions but we still want to give users an opportunity to send the transaction even if the simulation has failed. And for that we want to show the expected fee the user’s gonna pay

4

Can you please share the error message? Also what version of SDK are you using? and an output for the fuelup show would be appreciated

5

The error message depends on the simulation error. Again, it can be anything, any error from a smart contract. For example, when the contract reverts based on some condition.

We’ve been encountering this problem with different SDK versions. The latest one is 0.92.1.

This should have nothing to do with the local fuelup versions, because we’re interacting with the contracts deployed on testnet.

I think that the problem is in the fact that provider.getTransactionCost function executes the transaction simulation first to calculate the fee. If the transaction fails during the simulation, the calculation stops

6

Hi @mpoplavkov you are correct in that if there is there is an error in executing the dry run of the transaction, that error will be thrown and thus the cost will not be returned. At the moment I see this as correct behaviour.

As a wallet, we’re performing a simulation of transactions but we still want to give users an opportunity to send the transaction even if the simulation has failed. And for that we want to show the expected fee the user’s gonna pay

I’m curious about what benefit there may be in allowing a user to intentionally submit a transaction that will fail, could you elaborate a bit more on this use case?

In all likelihood, correcting that transaction so that it may be successful may increase/decrease gas costs, and so even if the gas cost was returned in the event of an error, it would not be representative of what’s required to make the transaction succeed.

7

We cannot guarantee that the transaction will fail if the simulation failed.

An example of a use case: when swapping tokens on a DEX and specifying some slippage, the simulation might fail but the user still might want to send the transaction, which can succeed in case the state of the DEX changes.

8

Thanks for the clarification @mpoplavkov

That’s a valid use case, I’ve created this issue so that we can do the necessary refactor to accommodate for your use case.

Thanks for raising this.

EDIT: Please see comment below

1 Like
9

Upon discussion with @Torres-ssf , he enlightened me to the fact that the receipts array that will be present within the FuelError metadata property, which can will contain the gasUsed

So once you handle this error, you can use this property calculate the gas used (in a similar fashion to this method)

Please note though, as I had mentioned that this gas used more than likely isn’t an accurate representation of the gas that would be used should the transaction be successfully dry run.

Please let me know if this works for you @mpoplavkov

10

Thanks, looks like that’s what I need. Do you think that functionality should be available in the SDK? Or should we calculate the gas used on our side?

11

Hey @mpoplavkov I supposed we could expose the gasUsedFromReceipts method but I would want to caution users that this may not be an accurate representation of the gas that would be used should the transaction be successfully executed, and so for that reason it may not be best to encourage it’s usage in most cases. But for your specific use case it’s applicable, as long as you ensure that your user flows properly accommodate for such scenarios.

1 Like
12

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.