fix: incorrect standard swap gas fee estimation

[matthewwalsh0]

Description

Fix incorrect non-smart gas fee estimations due to the use of an empty estimated base fee.

Related issues

Fixes: #28088

Manual testing steps

See issue.

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Extension Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

[martahj]

I'm not sure if this fixes the issue.

I'm using an account with 0.004029351477 ETH.

When I go to make a transaction, the estimated gas fee is 0.00334, but I still see a warning message saying I need an additional 0.0044+ ETH to make the transaction. It says the estimated fee is 0.00334 ETH ($8.40) and the max fee is $10.22, which would mean the max fee in ETH would be 0.004063666667. This is a little over my current ETH balance, so it's correct to show the warning, but the additional ETH needed is too high; it says I need basically the full amount, not the difference between the current balance and the estimated fee.

I then send the account 0.00005 ETH to that account, bringing the total balance to 0.004079351477032958 ETH. At this point, the message should go away because the account is sufficiently funded based on the max fee presented, but when I retry the swap the insufficient funds message persists.

[matthewwalsh0]

I'm not sure if this fixes the issue.

The core problem shown in the issue video is that the estimated gas fee in 12.6 is substantially less than in 12.5, to the point that when we get an insufficient fee response from the smart transaction API, it doesn't make sense since our displayed max fee is less than our total balance. This PR resolves that specific problem.

I think you've also identified a separate pre-existing issue in the ReviewQuote component that was introduced when smart transaction support was added. It's difficult to test, but my theory is:

1. When smart transactions are enabled, we render the gas fee estimates from the getFees call to the remote API.
2. If this request fails due an insufficient balance (as shown in this issue also), we render the values from the error response into the warning message, specifically currentBalanceWei and balanceNeededWei - currentBalanceWei.
3. The problem is that if the API request fails, how can we then locate the smart transaction fees to render?
4. We instead fallback to the standard gas fee estimation calculation using the gas fee flows and gas API which are slightly different to the smart transaction fees hence the disparity you've noticed in the desired balance in the warning, versus the rendered max fee.
5. One solution here could be to render the balance needed directly from the error response?

Meaning this PR should fix the regression from version 12.5, though I believe the misleading math you identified is out of scope. We could try verify the above theory by repeating your steps on 12.5?

[metamaskbot]

Builds ready [899a36f]

• builds: chrome, firefox
• builds (beta): chrome
• builds (flask): chrome, firefox
• builds (MMI): chrome, firefox
• builds (test): chrome, firefox
• builds (test-flask): chrome, firefox
• build viz: Build System
• mv3: Background Module Init Stats
• mv3: UI Init Stats
• mv3: Module Load Stats
• mv3: Bundle Size Stats
• mv2: E2e Actions Stats
• code coverage: Report
• storybook: Storybook
• typescript migration: Dashboard
• all artifacts
• bundle viz:

  • background: 0, 1, 2, 3, 4, 5, 6
  • common: 0, 1, 10, 11, 2, 3, 4, 5, 6, 7, 8, 9
  • content-script: 0
  • offscreen: 0
  • ui: 0, 1, 10, 11, 12, 2, 3, 4, 5, 6, 7, 8, 9

Page Load Metrics (1931 ± 91 ms)

Platform	Page	Metric	Min (ms)	Max (ms)	Average (ms)	StandardDeviation (ms)	MarginOfError (ms)
Chrome	Home	firstPaint	183	2541	1790	524	252
		domContentLoaded	1720	2472	1891	186	89
		load	1773	2490	1931	189	91
		domInteractive	27	144	52	26	12
		backgroundConnect	12	109	39	30	14
		firstReactRender	50	304	103	50	24
		getState	5	59	27	22	11
		initialActions	0	1	0	0	0
		loadScripts	1239	2001	1397	172	83
		setupStore	11	91	29	26	12
		uiStartup	1938	3159	2165	282	136

Bundle size diffs [🚨 Warning! Bundle size has increased!]

• background: 68 Bytes (0.00%)
• ui: 28 Bytes (0.00%)
• common: 0 Bytes (0.00%)

[martahj]

Meaning this PR should fix the regression from version 12.5, though I believe the misleading math you identified is out of scope. We could try verify the above theory by repeating your steps on 12.5?

Ok, I was able to repro on 12.5 and made a ticket to tackle the underlying issue. PR lgtm.

[metamaskbot]

Missing release label release-12.6.0 on PR. Adding release label release-12.6.0 on PR and removing other release labels(release-12.7.0), as PR was cherry-picked in branch 12.6.0.