Cherry-pick 67eb0bca9e (#22997) to v11.10.0 #23002
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Update the hardfork in the transaction common used to estimate L1 optimism fees to London, fixing display of Layer 1 optimsim fees
The bug was that Layer 1 fees were not being displayed on the
confirmation screen for transactions on Optimism.
This was because `estimatedL1Fees` was null, because
`fetchEstimatedL1Fee` was failing, because
`TransactionFactory.fromTxData(txParams, { common })` in
`buildUnserializedTransaction` was throwing an error, because `txParams`
has a `type` === `2`, but EIP-1559 transactions are not supported on the
spurious dragon hardfork, which is what was being used in the `common`
configuration of that `TransactionFactory.fromTxData` call.
This became a problem after
https://github.com/MetaMask/core/pull/3817/files. That PR correctly
fixed a bug which could result in the transaction type being removed
from the `txMeta.txParams` when `addTransaction` in the tx controller
was called. With that bug fix, there was now a `type` present on the
`txParams` that got passed to the aforementioned
`TransactionFactory.fromTxData` call. Prior to that bug fix, there was
no `type` on `txParams` at that point, the ethereumjs-tx
TransactionFactory was treating these transactions as legacy
transactions, and so was constructing a type 0 transaction, and the fact
that the hardfork was spurious dragon was not a problem
This PR fixes the problem by updating the hardfork param used in the
`common` configuration of that `TransactionFactory.fromTxData` call.
This should not have a functional effect, as this will cause no change
in data and value of the tx passed to the smart contract to generate an
fee estimate, except that this may result in more accurate L1 fee
estimates (that is not certain though).
Fixes: #22945
1. Create a transaction on OP Mainnet
2. Click "Fee details" on the confirmation screen
3. The layer 1 fee details should be visible
- [ ] I’ve followed [MetaMask Coding
Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md).
- [ ] I've clearly explained what problem this PR is solving and how it
is solved.
- [ ] I've linked related issues
- [ ] I've included manual testing steps
- [ ] I've included screenshots/recordings if applicable
- [ ] I’ve included tests if applicable
- [ ] I’ve documented my code using [JSDoc](https://jsdoc.app/) format
if applicable
- [ ] I’ve applied the right labels on the PR (see [labeling
guidelines](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/LABELING_GUIDELINES.md)).
Not required for external contributors.
- [ ] I’ve properly set the pull request status:
- [ ] In case it's not yet "ready for review", I've set it to "draft".
- [ ] In case it's "ready for review", I've changed it from "draft" to
"non-draft".
- [ ] 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.
Contributor
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry pick of #22997 to v11.10.0. That PR's description is below
Update the hardfork in the transaction common used to estimate L1 optimism fees to London, fixing display of Layer 1 optimsim fees
The bug was that Layer 1 fees were not being displayed on the confirmation screen for transactions on Optimism.
This was because
estimatedL1Feeswas null, becausefetchEstimatedL1Feewas failing, becauseTransactionFactory.fromTxData(txParams, { common })inbuildUnserializedTransactionwas throwing an error, becausetxParamshas atype===2, but EIP-1559 transactions are not supported on the spurious dragon hardfork, which is what was being used in thecommonconfiguration of thatTransactionFactory.fromTxDatacall.This became a problem after
https://github.com/MetaMask/core/pull/3817/files. That PR correctly fixed a bug which could result in the transaction type being removed from the
txMeta.txParamswhenaddTransactionin the tx controller was called. With that bug fix, there was now atypepresent on thetxParamsthat got passed to the aforementionedTransactionFactory.fromTxDatacall. Prior to that bug fix, there was notypeontxParamsat that point, the ethereumjs-tx TransactionFactory was treating these transactions as legacy transactions, and so was constructing a type 0 transaction, and the fact that the hardfork was spurious dragon was not a problemThis PR fixes the problem by updating the hardfork param used in the
commonconfiguration of thatTransactionFactory.fromTxDatacall. This should not have a functional effect, as this will cause no change in data and value of the tx passed to the smart contract to generate an fee estimate, except that this may result in more accurate L1 fee estimates (that is not certain though).Fixes: #22945