status-im / status-mobile

a free (libre) open source, mobile OS for Ethereum
https://status.app
Mozilla Public License 2.0
3.88k stars 984 forks source link

Fallback failed with "max fee per gas less than block base fee" when confirming the transaction #20027

Closed pavloburykh closed 1 month ago

pavloburykh commented 3 months ago

I am often facing this error when confirming transaction.

Steps:

  1. Try to send send transactions on different networks i.e L1/L2
  2. See if there is no error after confirming transaction with password

Actual result: Fallback failed with "max fee per gas less than block base fee" often occurs after transaction confirmation.

Status-debug-logs - 2024-05-14T150744.727.zip

photo_2024-05-14 15 06 04

As was mentioned by @alaibe here

This is first time i see this error, it looks like a different error from this bug. Even if we recompute every x seconds, initially this shouldn't happen

However we have this check on backend:

if baseFee.Cmp(perc20) >= 0 {
      maxFeePerGasMedium = baseFee
  } else {
      maxFeePerGasMedium = perc20
  }

Which means that we already ensure base fee is lower than max fee per gas medium. It could be a rounding issue on mobile?

Additional Information

briansztamfater commented 3 months ago

So, based on logs, some research on our implementation and the difficulty to reproduce, I would say this is related to Infura rate limits.

Check this comment:

Could infura rate limit be the reason? I am not sure if we are obtaining baseFee values from Infura and that is causing error sometimes 🤔 . https://github.com/status-im/status-desktop/issues/14571#issuecomment-2122859094

And response from Sale:

@briansztamfater yes, and yes we fetch not only the baseFee from Infura, but many other things while calculating the best route. https://github.com/status-im/status-desktop/issues/14571#issuecomment-2123916222

I'd say to mark this issue with status-go label, and maybe revisit it later when rate limits issues are solved. WDYT @pavloburykh @J-Son89?

J-Son89 commented 3 months ago

Thanks for researching @briansztamfater , sounds good by me!

pavloburykh commented 3 months ago

I'd say to mark this issue with status-go label, and maybe revisit it later when rate limits issues are solved. WDYT @pavloburykh @J-Son89?

Agree. Thanx for investigation @briansztamfater

OmarBasem commented 1 month ago

I'd say to mark this issue with status-go label, and maybe revisit it later when rate limits issues are solved.

Is there any open related issue to be linked to know when to revisit this issue? cc @briansztamfater @J-Son89

J-Son89 commented 1 month ago

So we should probably check with @dlipicar, @iurimatias or @alaibe about the status of the proxy server for helping with rate limits. If that is in place then I guess it is not related to that and we need to handle this some other way.

alaibe commented 1 month ago

@J-Son89 how is it related to the proxy and rate limit?

Regarding this specific issue, some changed happened to status-go which change how fees are computed and this error should not happens anymore: https://github.com/status-im/status-go/commit/fb261e4a0ed55e6c90f175974abf24ad1257393d

Regarding the proxy, the initial version won't have any cache implemented, also i am quite sure we should not cache call related to fees

churik commented 1 month ago

Will close for now and reopen if still the case in router v2