-
-
Notifications
You must be signed in to change notification settings - Fork 185
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
Retrieve global provider and block tracker dynamically #4004
Draft
matthewwalsh0
wants to merge
9
commits into
main
Choose a base branch
from
feat/dynamic-global-provider-block-tracker
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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
Dynamically retrieve selected network client when required. Throw or ignore in all public methods and helpers. Replace helper options with network client.
Cache global nonce tracker after first creation.
13 tasks
pedronfigueiredo
added a commit
to MetaMask/metamask-extension
that referenced
this pull request
Mar 26, 2024
## **Description** The temporary solution is to: - Prevent two network controller requests by: - Patch the network controller so that the lookup on initializeProvidercan be avoided. - Call that initializeProvider with the lookup: false argument right after the network controller is constructed - Call await this.networkController.lookupNetwork(); at the end of the metamask controller if the onboarding has been completed - Call await this.networkController.lookupNetwork(); once the onboarding complete state changes - Prevent one accounts tracker request by: - Moving the blockTracker event listener from the constructor of the controller to the start function The long term solution will be [#23005](#23005) (currently blocked by [#4004 on core](MetaMask/core#4004). ## **Related issues** Fixes: MetaMask/MetaMask-planning#881 ## **Manual testing steps** 1. Add `await new Promise((resolve) => setTimeout(resolve, 10000));` to the top of initialize on the background.js file 2. Build the app 3. Load extension and immediately open the network tab on the background console before the app initializes 4. No requests should happen ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** https://github.com/MetaMask/metamask-extension/assets/7499938/73513327-90fb-4e9f-8af2-aa41c731b647 ### **After** https://github.com/MetaMask/metamask-extension/assets/7499938/d6dee1c6-fa13-48c8-9fe2-520e3d43d0b3 ## **Pre-merge author checklist** - [ ] 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". ## **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. --------- Co-authored-by: Dan J Miller <danjm.com@gmail.com>
pedronfigueiredo
added a commit
to MetaMask/metamask-extension
that referenced
this pull request
Mar 26, 2024
## **Description** The temporary solution is to: - Prevent two network controller requests by: - Patch the network controller so that the lookup on initializeProvidercan be avoided. - Call that initializeProvider with the lookup: false argument right after the network controller is constructed - Call await this.networkController.lookupNetwork(); at the end of the metamask controller if the onboarding has been completed - Call await this.networkController.lookupNetwork(); once the onboarding complete state changes - Prevent one accounts tracker request by: - Moving the blockTracker event listener from the constructor of the controller to the start function The long term solution will be [#23005](#23005) (currently blocked by [#4004 on core](MetaMask/core#4004). ## **Related issues** Fixes: MetaMask/MetaMask-planning#881 ## **Manual testing steps** 1. Add `await new Promise((resolve) => setTimeout(resolve, 10000));` to the top of initialize on the background.js file 2. Build the app 3. Load extension and immediately open the network tab on the background console before the app initializes 4. No requests should happen ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** https://github.com/MetaMask/metamask-extension/assets/7499938/73513327-90fb-4e9f-8af2-aa41c731b647 ### **After** https://github.com/MetaMask/metamask-extension/assets/7499938/d6dee1c6-fa13-48c8-9fe2-520e3d43d0b3 ## **Pre-merge author checklist** - [ ] 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". ## **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. --------- Co-authored-by: Dan J Miller <danjm.com@gmail.com>
20 tasks
pedronfigueiredo
added a commit
to MetaMask/metamask-extension
that referenced
this pull request
Mar 26, 2024
…) (#23730) ## **Description** The temporary solution is to: - Prevent two network controller requests by: - Patch the network controller so that the lookup on initializeProvidercan be avoided. - Call that initializeProvider with the lookup: false argument right after the network controller is constructed - Call await this.networkController.lookupNetwork(); at the end of the metamask controller if the onboarding has been completed - Call await this.networkController.lookupNetwork(); once the onboarding complete state changes - Prevent one accounts tracker request by: - Moving the blockTracker event listener from the constructor of the controller to the start function The long term solution will be [#23005](#23005) (currently blocked by [#4004 on core](MetaMask/core#4004). ## **Related issues** Fixes: MetaMask/MetaMask-planning#881 ## **Manual testing steps** 1. Add `await new Promise((resolve) => setTimeout(resolve, 10000));` to the top of initialize on the background.js file 2. Build the app 3. Load extension and immediately open the network tab on the background console before the app initializes 4. No requests should happen ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** https://github.com/MetaMask/metamask-extension/assets/7499938/73513327-90fb-4e9f-8af2-aa41c731b647 ### **After** https://github.com/MetaMask/metamask-extension/assets/7499938/d6dee1c6-fa13-48c8-9fe2-520e3d43d0b3 ## **Pre-merge author checklist** - [ ] 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". ## **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. --------- <!-- Please submit this PR as a draft initially. Do not mark it as "Ready for review" until the template has been completely filled out, and PR status checks have passed at least once. --> ## **Description** <!-- Write a short description of the changes included in this pull request, also include relevant motivation and context. Have in mind the following questions: 1. What is the reason for the change? 2. What is the improvement/solution? --> [![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/MetaMask/metamask-extension/pull/23730?quickstart=1) ## **Related issues** Fixes: ## **Manual testing steps** 1. Go to this page... 2. 3. ## **Screenshots/Recordings** <!-- If applicable, add screenshots and/or recordings to visualize the before and after of your change. --> ### **Before** <!-- [screenshots/recordings] --> ### **After** <!-- [screenshots/recordings] --> ## **Pre-merge author checklist** - [ ] I’ve followed [MetaMask Coding Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md). - [ ] 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](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. ## **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. Co-authored-by: Dan J Miller <danjm.com@gmail.com>
@matthewwalsh0 @pedronfigueiredo Is this still being pursued? |
@legobeat thanks for checking in on this. It has been handed over to the transactions team. More context here: https://consensys.slack.com/archives/C05B78N1T9B/p1714756558259079. cc: @dbrans |
6 tasks
3 tasks
@matthewwalsh0 I'm continuing this PR in #4359 |
dbrans
changed the title
Retrieve global provider and block tracker dynamically
COMMANDEERED by #4359: Retrieve global provider and block tracker dynamically
Jun 4, 2024
dbrans
changed the title
COMMANDEERED by #4359: Retrieve global provider and block tracker dynamically
Retrieve global provider and block tracker dynamically
Jul 30, 2024
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Explanation
Currently the global
provider
andblockTracker
instances are required as constructor options in theTransactionController
.This means the clients must have the global provider available when the controller instance is created, usually on startup.
In order to support construction of the
TransactionController
before these are available, to facilitate use cases such as disabling provider access until onboarding is complete, this PR does the following:provider
andblockTracker
constructor options.getGlobalProviderAndBlockTracker
callback option.blockTracker
,getEthQuery
andchainId
constructor options in the helper classes with a singlegetNetworkClient
option since all the previous values are either all available or all unavailable, meaning the associated validation becomes much simpler.nonceTracker
when first used since it is an alternate package and still requires aprovider
argument.MethodRegistry
instance since it is also an alternate package and requires aprovider
argument.onBootCleanup
logic into the public methodinitApprovedTransactions
so it can be called by the client explicitly when suitable.MultichainTrackingHelper
.Note that any additional complexity or logic surrounding the global network specifically is temporary and can be removed once the clients enable the multichain flag, at which point all network clients and helpers will be dynamically synchronised with the
NetworkController
state.Changelog
@metamask/transaction-controller
[PENDING]
Checklist