Skip to content

feat: NetworkController.upsertNetworkConfiguration allow upsert by networkConfigurationId#4614

Merged
jiexi merged 2 commits intomainfrom
jl/mme-26309/network-controller-allow-upsert-by-networkClientId
Aug 15, 2024
Merged

feat: NetworkController.upsertNetworkConfiguration allow upsert by networkConfigurationId#4614
jiexi merged 2 commits intomainfrom
jl/mme-26309/network-controller-allow-upsert-by-networkClientId

Conversation

@jiexi
Copy link
Copy Markdown
Member

@jiexi jiexi commented Aug 15, 2024

Explanation

Currently it is not possible to change the rpcUrl for an existing network configuration without first removing it then re-adding it. This poses an issue on extension when the rpcUrl for the currently selected network is changed via the NetworkForm. The NetworkForm first removes the existing networkClient which causes the SelectedNetworkController to replace any references to the networkClientId being removed with the selectedNetworkClientId, but the problem is that the selectedNetworkClientId is no longer valid at that point. Really what we want in this case is to allow the network configuration to be updated in place by id, but only if the rpcUrl isn't changing to one that already exists on a different network configuration.

This PR achieves that by changing NetworkController.upsertNetworkConfiguration() to accept an optional id in the NetworkConfiguration param. When provided, it MUST match to an existing network configuration. Additionally, it must match the id for any network configuration that may match the target rpcUrl

References

Related: MetaMask/metamask-extension#26309

Changelog

@metamask/network-controller

  • ADDED: NetworkController.upsertNetworkConfiguration() accepts an optional id property on the NetworkConfiguration param. It now allows a network configuration to have its rpcUrl updated in place when an id is specified, but only if that new rpcUrl does not already exist on a different network configuration.

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've highlighted breaking changes using the "BREAKING" category above as appropriate

@jiexi jiexi requested a review from a team August 15, 2024 18:56
@jiexi
Copy link
Copy Markdown
Member Author

jiexi commented Aug 15, 2024

@metamaskbot publish-preview

@github-actions
Copy link
Copy Markdown
Contributor

Preview builds have been published. See these instructions for more information about preview builds.

Expand for full list of packages and versions.
{
  "@metamask-previews/accounts-controller": "18.0.0-preview-04d601b",
  "@metamask-previews/address-book-controller": "5.0.0-preview-04d601b",
  "@metamask-previews/announcement-controller": "7.0.0-preview-04d601b",
  "@metamask-previews/approval-controller": "7.0.2-preview-04d601b",
  "@metamask-previews/assets-controllers": "37.0.0-preview-04d601b",
  "@metamask-previews/base-controller": "6.0.2-preview-04d601b",
  "@metamask-previews/build-utils": "3.0.0-preview-04d601b",
  "@metamask-previews/chain-controller": "0.1.1-preview-04d601b",
  "@metamask-previews/composable-controller": "7.0.0-preview-04d601b",
  "@metamask-previews/controller-utils": "11.0.2-preview-04d601b",
  "@metamask-previews/ens-controller": "13.0.1-preview-04d601b",
  "@metamask-previews/eth-json-rpc-provider": "4.1.3-preview-04d601b",
  "@metamask-previews/gas-fee-controller": "19.0.1-preview-04d601b",
  "@metamask-previews/json-rpc-engine": "9.0.2-preview-04d601b",
  "@metamask-previews/json-rpc-middleware-stream": "8.0.2-preview-04d601b",
  "@metamask-previews/keyring-controller": "17.1.2-preview-04d601b",
  "@metamask-previews/logging-controller": "5.0.0-preview-04d601b",
  "@metamask-previews/message-manager": "10.0.2-preview-04d601b",
  "@metamask-previews/name-controller": "8.0.0-preview-04d601b",
  "@metamask-previews/network-controller": "20.1.0-preview-04d601b",
  "@metamask-previews/notification-controller": "6.0.0-preview-04d601b",
  "@metamask-previews/notification-services-controller": "0.2.1-preview-04d601b",
  "@metamask-previews/permission-controller": "11.0.0-preview-04d601b",
  "@metamask-previews/permission-log-controller": "3.0.0-preview-04d601b",
  "@metamask-previews/phishing-controller": "10.1.1-preview-04d601b",
  "@metamask-previews/polling-controller": "9.0.1-preview-04d601b",
  "@metamask-previews/preferences-controller": "13.0.1-preview-04d601b",
  "@metamask-previews/profile-sync-controller": "0.2.1-preview-04d601b",
  "@metamask-previews/queued-request-controller": "4.0.0-preview-04d601b",
  "@metamask-previews/rate-limit-controller": "6.0.0-preview-04d601b",
  "@metamask-previews/selected-network-controller": "17.0.0-preview-04d601b",
  "@metamask-previews/signature-controller": "18.0.1-preview-04d601b",
  "@metamask-previews/transaction-controller": "35.1.1-preview-04d601b",
  "@metamask-previews/user-operation-controller": "14.0.1-preview-04d601b"
}

Gudahtt
Gudahtt previously approved these changes Aug 15, 2024
Copy link
Copy Markdown
Member

@Gudahtt Gudahtt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@jiexi
Copy link
Copy Markdown
Member Author

jiexi commented Aug 15, 2024

Tested by manually copying NetworkController changes into this Extension branch that gets rid of the network removal when editing an existing network

@jiexi jiexi merged commit d5e5c62 into main Aug 15, 2024
@jiexi jiexi deleted the jl/mme-26309/network-controller-allow-upsert-by-networkClientId branch August 15, 2024 20:23
jiexi added a commit to MetaMask/metamask-extension that referenced this pull request Aug 16, 2024
…Form update in-place rather than remove and add for rpcUrl changes (#26453)

<!--
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**

Currently it is not possible to change the rpcUrl for an existing
network configuration without first removing it then re-adding it. This
poses an issue on extension when the rpcUrl for the currently selected
network is changed via the `NetworkForm`. The NetworkForm first removes
the existing networkClient which causes the SelectedNetworkController to
replace any references to the networkClientId being removed with the
selectedNetworkClientId, but the problem is that the
selectedNetworkClientId is no longer valid at that point and leaves the
SelectedNetworkController in a corrupted state.

Really what we want in this case is to allow the network configuration
to be updated in place by id, but only if the rpcUrl isn't changing to
one that already exists on a different network configuration.

This PR achieves that by getting rid of the
`removeNetworkConfiguration()` call triggered by `NetworkForm` and
patching the `NetworkController` with changes from
MetaMask/core#4614 which allow network
configurations to have their rpcUrl updated in place. It also keeps the
existing patch that removed a `lookupNetwork()` call in
`initializeProvider()`.

[![Open in GitHub
Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/MetaMask/metamask-extension/pull/26453?quickstart=1)

## **Related issues**

Related: #26309

## **Manual testing steps**

1. Open extension in expanded view
2. Visit the Settings -> Networks
3. Add a network manually and add an rpc provider for Arbitrum One (for
your convenience, [chainlist.org](https://chainlist.org/chain/42161))
4. In the extension service worker console note the state via
`chrome.storage.local.get(console.log)` for
NetworkController.networkConfigurations
5. Visit the Network Form for that Network
6. Change the rpcUrl to a different valid one for Arbitrum 
7. In the extension service worker console check state via
`chrome.storage.local.get(console.log)`, the id for the network
configuration that was just edited should not have changed in
NetworkController.networkConfigurations
8. Visit a dapp, switch the chain to Arbitrum 
```
await window.ethereum.request({
  "method": "eth_requestAccounts",
});
await window.ethereum.request({
  "method": "wallet_switchEthereumChain",
  "params": [
    {
      "chainId": "0xa4b1"
    }
  ]
});
```
7. In the extension service worker console check state via
`chrome.storage.local.get(console.log)`, the dapp should have an entry
for the network client we added above SelectedNetworkController.domains
8. Again, Change the rpcUrl to a different valid one for Arbitrum 
9. In the extension service worker console check state via
`chrome.storage.local.get(console.log)`, the dapp should still be
pointed at the same network client id in
SelectedNetworkController.domains which should still exist in
NetworkController.networkConfigurations

## **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**

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask
Extension Coding
Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I’ve included tests if applicable
- [x] 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.
jiexi added a commit to MetaMask/metamask-extension that referenced this pull request Aug 16, 2024
…Form update in-place rather than remove and add for rpcUrl changes (#26453)

<!--
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.
-->

Currently it is not possible to change the rpcUrl for an existing
network configuration without first removing it then re-adding it. This
poses an issue on extension when the rpcUrl for the currently selected
network is changed via the `NetworkForm`. The NetworkForm first removes
the existing networkClient which causes the SelectedNetworkController to
replace any references to the networkClientId being removed with the
selectedNetworkClientId, but the problem is that the
selectedNetworkClientId is no longer valid at that point and leaves the
SelectedNetworkController in a corrupted state.

Really what we want in this case is to allow the network configuration
to be updated in place by id, but only if the rpcUrl isn't changing to
one that already exists on a different network configuration.

This PR achieves that by getting rid of the
`removeNetworkConfiguration()` call triggered by `NetworkForm` and
patching the `NetworkController` with changes from
MetaMask/core#4614 which allow network
configurations to have their rpcUrl updated in place. It also keeps the
existing patch that removed a `lookupNetwork()` call in
`initializeProvider()`.

[![Open in GitHub
Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/MetaMask/metamask-extension/pull/26453?quickstart=1)

Related: #26309

1. Open extension in expanded view
2. Visit the Settings -> Networks
3. Add a network manually and add an rpc provider for Arbitrum One (for
your convenience, [chainlist.org](https://chainlist.org/chain/42161))
4. In the extension service worker console note the state via
`chrome.storage.local.get(console.log)` for
NetworkController.networkConfigurations
5. Visit the Network Form for that Network
6. Change the rpcUrl to a different valid one for Arbitrum
7. In the extension service worker console check state via
`chrome.storage.local.get(console.log)`, the id for the network
configuration that was just edited should not have changed in
NetworkController.networkConfigurations
8. Visit a dapp, switch the chain to Arbitrum
```
await window.ethereum.request({
  "method": "eth_requestAccounts",
});
await window.ethereum.request({
  "method": "wallet_switchEthereumChain",
  "params": [
    {
      "chainId": "0xa4b1"
    }
  ]
});
```
7. In the extension service worker console check state via
`chrome.storage.local.get(console.log)`, the dapp should have an entry
for the network client we added above SelectedNetworkController.domains
8. Again, Change the rpcUrl to a different valid one for Arbitrum
9. In the extension service worker console check state via
`chrome.storage.local.get(console.log)`, the dapp should still be
pointed at the same network client id in
SelectedNetworkController.domains which should still exist in
NetworkController.networkConfigurations

<!-- If applicable, add screenshots and/or recordings to visualize the
before and after of your change. -->

<!-- [screenshots/recordings] -->

<!-- [screenshots/recordings] -->

- [x] I've followed [MetaMask Contributor
Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask
Extension Coding
Standards](https://github.com/MetaMask/metamask-extension/blob/develop/.github/guidelines/CODING_GUIDELINES.md).
- [x] I've completed the PR template to the best of my ability
- [x] I’ve included tests if applicable
- [x] 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 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants