-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InsufficientFeeAmount on test accounts. #1361
Comments
Hi, thanks for informing us of this issue. Since you are testing on beta-5, would you be able to share the relevant wallet address and/or transaction id so that we have some more insight into what is happening here? |
Hi, thanks for the response! Unfortunately, I can't provide the transaction ID, because the transaction's Result returns Error, and the tx_id is in the Ok type (FuelCallResponse)... But I can provide the wallet address, and the "good" part here is that I think almost any transaction on that wallet should return this error, so this should be easy to reproduce. Here's the wallet address: |
.env file
|
@MujkicA @hal3e Guys, I've tried the suggested workaround for estimating transaction cost and bumping it by ~20%, but unfortunately the InsufficientFeeAmount pops up even for the estimate_transaction_cost() itself. So I need the estimation, but the estimation itself triggers the issue. What can I do in this case? Here, I get the Err while unwrapping on line 257. |
You can try using the wallets entire base asset balance as temporary workaround let wallet = Wallet::from_address(addr, Some(provider.clone()));
let balance = provider.get_asset_balance(wallet.address(), BASE_ASSET_ID).await?;
call_handler.add_custom_asset(BASE_ASSET_ID, balance, None); |
We (me and @MujkicA) have found a solid workaround for this issue, so thanks so much for all the help! Won't be closing the issue until the official fix for this is out. Thank you guys. |
Hey guys, how does the progress on this look like? |
I'm also running into this issue, I'm unable to interact with any contracts I deploy on testnet via rust. Here is my code for a local reproduction (it is very simple): https://github.com/enviodev/fuel-greeter/pull/1/files#r1616211590 |
The workaround for now is to manually set a high script gas limit on your contract call via the Here is a rough example: let gas_limit = provider.consensus_parameters().max_gas_per_tx() * 0.8;
let res = instance
.methods()
.your_method().with_tx_policies(TxPolicies::default().with_script_gas_limit(gas_limit)))
.call()
.await?; |
Thank you this is working for me.
Appreciate the help 🙏 |
I have a similar error but with much higher gas limits :
The function is trivial: fn initialize() {
let sender = msg_sender().unwrap();
initialize_ownership(sender);
} When I set script gas limit as suggested above to the expected value 1000000000000, I'm getting another error:
|
Does the error persist if you set the script gas limit to: let gas_limit = provider.consensus_parameters().tx_params().max_gas_per_tx() * 0.8; |
The issue is solved for me after upgrading the SDK to 0.63.0 |
Hi! So when writing a Rust order matcher with the fuels crate, all my test accounts eventually become unusable with this error message:
[15:11:51][ERROR] An error occurred while matching: IO error: Response errors; Validity(InsufficientFeeAmount { expected: 326087, provided: 323226 })
I'm sorry I cannot provide a specific scenario to reproduce, but it would usually go like this:
I unfortunately don't know of an easier or more reliable way to reproduce this. The only way is, I have a wallet and a private key for which this problem already exists. If needed, I can give it to you: it's a test account, so it's of no importance.
P.S. This is using the fuels crate version 0.55.1 on Manjaro Linux, on Beta 5 (related to my comment in #1342, it's the same issue)
The text was updated successfully, but these errors were encountered: