-
Notifications
You must be signed in to change notification settings - Fork 5k
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: Fix currentNetwork
selector when current network config is missing
#26327
Conversation
4a3bb7b
to
e4093a9
Compare
…sing The `providerConfig` state is not guaranteed to match a built-in or custom network. It should in the vast majority of cases, but there are some edge cases where that would not hold true. For example: * If the wallet crashed partway through removing the current network * If the user has had the same network selected since before we introduced the `networkConfigurations` state The `currentNetwork` selector has been updated to handle this case by returning a configuration object constructed from the `providerConfig` state directly. Fixes #26320
ec6b27f
to
c38a3f5
Compare
Quality Gate passedIssues Measures |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #26327 +/- ##
========================================
Coverage 70.04% 70.04%
========================================
Files 1411 1411
Lines 50029 50034 +5
Branches 13815 13820 +5
========================================
+ Hits 35042 35046 +4
- Misses 14987 14988 +1 ☔ View full report in Codecov by Sentry. |
</div> | ||
<span | ||
class="mm-box mm-text mm-text--body-sm mm-text--ellipsis mm-box--color-text-default" | ||
data-testid="network-display" | ||
/> | ||
> | ||
Test initial state |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The test fixtures used here were of the type affected by this change: providerConfig
was not a built-in or custom network. Probably not intentional, but I didn't dig in further. This snapshot change is not wrong or totally unexpected at least.
* | ||
* @param {Record<string, unknown>[]} allNetworks - All network configurations. | ||
* @param {Record<string, unknown>} providerConfig - The configuration for the current network's provider. | ||
* @returns {{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a JSDoc block so that tsc
could help spot any instances where this change was breaking.
Specifically the only difference in output before and after is that the id
property is now optional, whereas before it was guaranteed to exist on the returned object in some cases (if an object was returned at all). But luckily nothing was relying on that.
return allNetworks.find(filter); | ||
return ( | ||
allNetworks.find(filter) ?? { | ||
chainId: providerConfig.chainId, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The providerConfig.type
property is being excluded here because that's not an expected network configuration property.
id
is excluded as well, since if it is set here it must be invalid (the filter above didn't find anything matching it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have we removed instances like the one causing this error expecting an id
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like it's still in this file down on line 1912?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify, the id
property is still expected to be present in cases where providerConfig
matches a valid custom network configuration. It would cause problems if this selector was used where an id
must always present, but the line you linked works fine if id
is undefined
. If the current domain has a selected network configuration set, it'll find that it doesn't match undefined
and it will switch, which is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok right. The issue I was thinking of was when currentNetwork
is undefined not id
: https://metamask.sentry.io/issues/5660992353/?environment=production&project=273505&query=firstRelease%3A12.0.0&referrer=issue-stream&sort=freq&statsPeriod=90d&stream_index=12
Builds ready [c38a3f5]
Page Load Metrics (287 ± 301 ms)
Bundle size diffs [🚨 Warning! Bundle size has increased!]
|
Description
The
providerConfig
state is not guaranteed to match a built-in or custom network. It should in the vast majority of cases, but there are some edge cases where that would not hold true. For example:networkConfigurations
stateThe
currentNetwork
selector has been updated to handle this case by returning a configuration object constructed from theproviderConfig
state directly.Related issues
Fixes #26320
Manual testing steps
providerConfig
to a custom network that isn't present in the user's tracked network configurations:Screenshots/Recordings
N/A
Pre-merge author checklist
Pre-merge reviewer checklist