Skip to content
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

Fix #19941 - Correctly show network name and selection when chainIds collide #19947

Merged
merged 7 commits into from
Jul 13, 2023

Conversation

darkwing
Copy link
Contributor

Explanation

This bug was occurring because we were selecting the first network with a given chain ID. That means if there's a custom network with a chain ID that matches a pre-installed network (i.e. Mainnet having 0x1 and a localhost 0x1 chain, like the issue cites), we show the wrong network selected in the Network Picker despite switching to the correct network. This is a labeling issue, not a functionality issue.

To fix this issue, I fork the logic for retrieving the current network by checking to see if it's a custom network (by checking for type=rpc and searching for the network by configuration ID. If a pre-installed network, we use the chainId.

Screenshots/Screencaps

NetworkFix.mov

Manual Testing Steps

  1. Add a bunch of predefined networks like Avalanche, Polygon, etc.
  2. Start ganache with ganache --chain.chainId 1
  3. Add localhost with a chainID of 1
  4. Switch between all of the networks you've added and see that networks switch properly, the network picker shows the correct label, and the correct item in the network list shows as selected.

Pre-merge author checklist

  • I've clearly explained:
    • What problem this PR is solving
    • How this problem was solved
    • How reviewers can test my changes
  • Sufficient automated test coverage has been added

Pre-merge reviewer checklist

  • Manual testing (e.g. pull and build branch, run in browser, test code being changed)
  • PR is linked to the appropriate GitHub issue
  • IF this PR fixes a bug in the release milestone, add this PR to the release milestone

If further QA is required (e.g. new feature, complex testing steps, large refactor), add the Extension QA Board label.

In this case, a QA Engineer approval will be be required.

@darkwing darkwing requested a review from a team as a code owner July 10, 2023 20:43
@github-actions
Copy link
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.

const filter =
providerConfig.type === 'rpc'
? (network) => network.id === providerConfig.id
: (network) => network.chainId === currentChainId;
Copy link
Member

Choose a reason for hiding this comment

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

Thoughts on using provider.type instead? chainId works, but it makes the result order-dependent. type is reliably unique for built-in networks, so that should make this a little more reliable even if the order changes later.

It looks like providerConfig.type is available on the network list entries as network.providerType

Suggested change
: (network) => network.chainId === currentChainId;
: (network) => network.providerType === providerConfig.type;

Alternatively, since you've set the id field to the type for all of the built-in networks, maybe this would work:

Suggested change
: (network) => network.chainId === currentChainId;
: (network) => network.id === providerConfig.type;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Awesome idea!

Copy link
Contributor

@legobeat legobeat Jul 11, 2023

Choose a reason for hiding this comment

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

In my mind, the rpcUrl (if available) would be the most reliable. rpcUrl || chainId might do the trick?

This should also make custom RPCs more robust, I think (it looks like multiple custom RPCs with overlapping chainId can still collide if the url is not taken into account in either case).

(IMO more generally, it would make sense for multiple reasons that rpcUrl would become a mandatory field, which would mean simplified logic in places like this)

Copy link
Member

Choose a reason for hiding this comment

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

Using id might be more forwards-compatible if we start introducing more custom RPC fields alongside rpc URL, making it no longer unique. We did get a request to support additional headers, where the header might determine the chain.

@Gudahtt
Copy link
Member

Gudahtt commented Jul 11, 2023

The code looks good, but I'm seeing consistent e2e test failures for the test "finds all recent RPCs in history"

@darkwing darkwing force-pushed the 19941-selected-network branch 3 times, most recently from ce06ab6 to 2225629 Compare July 12, 2023 16:03
@metamaskbot
Copy link
Collaborator

Builds ready [2225629]
Page Load Metrics (1608 ± 45 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint1082381413316
domContentLoaded1456181016089445
load1456181016089445
domInteractive1456181016089445
Bundle size diffs
  • background: 0 bytes
  • ui: 238 bytes
  • common: 0 bytes

@codecov
Copy link

codecov bot commented Jul 12, 2023

Codecov Report

Merging #19947 (f1c94b4) into develop (2f03c0d) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop   #19947   +/-   ##
========================================
  Coverage    69.47%   69.48%           
========================================
  Files          988      988           
  Lines        37297    37301    +4     
  Branches      9980     9982    +2     
========================================
+ Hits         25912    25916    +4     
  Misses       11385    11385           
Impacted Files Coverage Δ
.../multichain/network-list-menu/network-list-menu.js 69.64% <100.00%> (+0.55%) ⬆️
ui/selectors/selectors.js 87.01% <100.00%> (+0.06%) ⬆️

... and 2 files with indirect coverage changes

@darkwing darkwing force-pushed the 19941-selected-network branch from 4a1b384 to c80a858 Compare July 12, 2023 19:16
@metamaskbot
Copy link
Collaborator

Builds ready [2225629]
Page Load Metrics (1565 ± 33 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint110158125136
domContentLoaded1436173315646933
load1436173415656933
domInteractive1436173315646933
Bundle size diffs
  • background: 0 bytes
  • ui: 238 bytes
  • common: 0 bytes

@darkwing darkwing force-pushed the 19941-selected-network branch 2 times, most recently from 6f07329 to 6c5156d Compare July 12, 2023 22:12
@darkwing darkwing force-pushed the 19941-selected-network branch 2 times, most recently from 76c7559 to 736065d Compare July 13, 2023 13:52
@metamaskbot
Copy link
Collaborator

Builds ready [f1c94b4]
Page Load Metrics (1655 ± 47 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint1121911412210
domContentLoaded1455182516549847
load1455182516559847
domInteractive1455182516549847
Bundle size diffs
  • background: 0 bytes
  • ui: 238 bytes
  • common: 0 bytes

@danjm
Copy link
Contributor

danjm commented Jul 13, 2023

The code looks good, but I'm seeing consistent e2e test failures for the test "finds all recent RPCs in history"

This was fixed with this change https://github.com/MetaMask/metamask-extension/pull/19947/files#diff-50c876d2ff4c618bf7018751413649df82021af47d93754663e8bf7522bea68fL199-L200

Previously, there were two networks in the fixtures with the same id, and one of those networks would result in a 404 if a request was sent to it. So metamask was attempting to connect to the wrong network.

@darkwing darkwing merged commit 719d8a4 into develop Jul 13, 2023
@darkwing darkwing deleted the 19941-selected-network branch July 13, 2023 18:29
@github-actions github-actions bot locked and limited conversation to collaborators Jul 13, 2023
@metamaskbot metamaskbot added the release-10.35.0 Issue or pull request that will be included in release 10.35.0 label Jul 13, 2023
@PeterYinusa PeterYinusa added release-10.34.0 Issue or pull request that will be included in release 10.34.0 and removed release-10.35.0 Issue or pull request that will be included in release 10.35.0 labels Jul 14, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
release-10.34.0 Issue or pull request that will be included in release 10.34.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: RPC requests are mixed while using different networks with same chainId
7 participants