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: wallet_addEthereumChain does not attach a result under certain conditions #26726

Merged
merged 3 commits into from
Aug 28, 2024

Conversation

adonesky1
Copy link
Contributor

@adonesky1 adonesky1 commented Aug 28, 2024

Description

Fix issue where wallet_addEthereumChain does not attach a result to the response object when the currently selected rpcUrl matches the request.

This would cause the request to get "stuck" in the QueuedRequestController queue, preventing the queue from progressing and causing confusing behavior.

Open in GitHub Codespaces

Related issues

Fixes: #26706

Manual testing steps

  1. Go to https://chainlist.org/?chain=56&search=blast
  2. Connect the wallet and add Blast Mainnet
    (For other chains it appears Chainlist cycles to the next rpcUrl you don't have which avoids this bug, so use Blast)
  3. After successfully adding the network, attempt to add Blast again. Nothing should happen.
  4. Then go to https://faucet.quicknode.com/blast/sepolia (or any dapp where your wallet isn't already connected) and attempt to connect
  5. You should be able to connect as usual

Screenshots/Recordings

Before

Screen.Recording.2024-08-28.at.1.37.50.PM.mov

After

Screen.Recording.2024-08-28.at.1.33.16.PM.mov

Pre-merge author checklist

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.

…he response object when the currently selected rpcUrl matches the request
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.

@adonesky1 adonesky1 marked this pull request as ready for review August 28, 2024 18:38
@adonesky1 adonesky1 requested a review from a team as a code owner August 28, 2024 18:38
@adonesky1 adonesky1 requested review from Gudahtt and seaona August 28, 2024 18:44
@Gudahtt
Copy link
Member

Gudahtt commented Aug 28, 2024

This change looks correct to me, but I am curious how it might have caused this problem. Wouldn't end() have triggered the QueuedRequestController to consider this as resolved? Why do we need result to be set for it to be resolved there?

@adonesky1
Copy link
Contributor Author

This change looks correct to me, but I am curious how it might have caused this problem. Wouldn't end() have triggered the QueuedRequestController to consider this as resolved? Why do we need result to be set for it to be resolved there.

I would have thought so too... which is certainly why this bug was introduced and unnoticed. And even when debugging I stared at it for a while thinking this should resolve the request. But apparently the rpc engine needs a result if an error is not specified in the end function... something to probably look into modifying in the JSON RPC Engine

@Gudahtt
Copy link
Member

Gudahtt commented Aug 28, 2024

Oh I see, I recall that now. Makes sense.

Gudahtt
Gudahtt previously approved these changes Aug 28, 2024
Copy link
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!

@adonesky1
Copy link
Contributor Author

seems like the chrome e2e test failure might relate to these brownouts? All the tests seem to be passing...

Screenshot 2024-08-28 at 1 55 50 PM

@@ -139,6 +139,7 @@ async function addEthereumChainHandler(
currentChainIdForDomain === chainId &&
currentRpcUrl === firstValidRPCUrl
) {
res.result = null;
Copy link
Member

Choose a reason for hiding this comment

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

Not a blocker, but curious how the JsonRpcEngine didn't end up throwing for this. AFAIK if we process all middlewares without a result we end up throwing an error?

Copy link
Member

Choose a reason for hiding this comment

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

It did throw an error in this case, and it was returned to the dapp. But the QueuedRequestController missed it for some reason.

But yeah, good point, how was this missed 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It actually did throw an error to the dapp as you can see in the after video

Copy link
Contributor Author

Choose a reason for hiding this comment

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

But the QueuedRequestController missed it for some reason.

Yeah... we should investigate this. I can create a ticket

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Gudahtt
Copy link
Member

Gudahtt commented Aug 28, 2024

Possibly; the initial failure is one we've always seen occasionally on CircleCI. The "Rerun failed tests" button always fails unless test artifacts have been uploaded during the failed run, so "Rerun failed workflows" needs to be used instead. I've just triggered that.

Copy link

codecov bot commented Aug 28, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.08%. Comparing base (d9e989e) to head (c4c185b).
Report is 15 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop   #26726      +/-   ##
===========================================
- Coverage    70.09%   70.08%   -0.01%     
===========================================
  Files         1413     1413              
  Lines        49255    49318      +63     
  Branches     13768    13780      +12     
===========================================
+ Hits         34524    34562      +38     
- Misses       14731    14756      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@metamaskbot
Copy link
Collaborator

Builds ready [2cf7859]
Page Load Metrics (71 ± 7 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint6815494199
domContentLoaded4210368136
load4910371147
domInteractive115526105
Bundle size diffs [🚨 Warning! Bundle size has increased!]
  • background: 14 Bytes (0.00%)
  • ui: 0 Bytes (0.00%)
  • common: 0 Bytes (0.00%)

Comment on lines 547 to 551
jest.spyOn(chainUtils, 'findExistingNetwork').mockReturnValue({
chainId: '0x1',
rpcUrl: 'https://mainnet.infura.io/v3/',
ticker: 'ETH',
});
Copy link
Contributor

Choose a reason for hiding this comment

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

guessing you can just modify the findNetworkConfigurationBy mock result because findExistingNetwork also checks the built in networks constant?

if so, can we modify this test to use a non-built-in network instead?

Copy link
Contributor

@jiexi jiexi Aug 28, 2024

Choose a reason for hiding this comment

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

if it wasnt* clear, this is a nit and totally ignorable. I'm mainly asking so we can avoid having to import and mock chainutils

Copy link
Contributor Author

Choose a reason for hiding this comment

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

addressed here: 4c93640

jiexi
jiexi previously approved these changes Aug 28, 2024
Copy link
Contributor

@jiexi jiexi left a comment

Choose a reason for hiding this comment

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

approving to avoid being a blocker. feel free to ignore nit

@adonesky1 adonesky1 dismissed stale reviews from jiexi and Gudahtt via 4c93640 August 28, 2024 21:24
@adonesky1 adonesky1 requested review from Gudahtt and jiexi August 28, 2024 21:24
jiexi
jiexi previously approved these changes Aug 28, 2024
Gudahtt
Gudahtt previously approved these changes Aug 28, 2024
@adonesky1 adonesky1 dismissed stale reviews from Gudahtt and jiexi via c4c185b August 28, 2024 21:48
@adonesky1 adonesky1 requested review from jiexi and Gudahtt August 28, 2024 21:48
Copy link

sonarcloud bot commented Aug 28, 2024

@adonesky1 adonesky1 merged commit fb61b0f into develop Aug 28, 2024
77 of 78 checks passed
@adonesky1 adonesky1 deleted the ad/fix-wallet_addEthereumChain-handler branch August 28, 2024 22:11
@github-actions github-actions bot locked and limited conversation to collaborators Aug 28, 2024
@metamaskbot metamaskbot added the release-12.5.0 Issue or pull request that will be included in release 12.5.0 label Aug 28, 2024
@metamaskbot
Copy link
Collaborator

Builds ready [c4c185b]
Page Load Metrics (82 ± 10 ms)
PlatformPageMetricMin (ms)Max (ms)Average (ms)StandardDeviation (ms)MarginOfError (ms)
ChromeHomefirstPaint771911112412
domContentLoaded53151782311
load58151822210
domInteractive168332157
Bundle size diffs [🚨 Warning! Bundle size has increased!]
  • background: 14 Bytes (0.00%)
  • ui: 0 Bytes (0.00%)
  • common: 0 Bytes (0.00%)

@gauthierpetetin gauthierpetetin added release-12.4.0 Issue or pull request that will be included in release 12.4.0 and removed release-12.5.0 Issue or pull request that will be included in release 12.5.0 labels Sep 11, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
release-12.4.0 Issue or pull request that will be included in release 12.4.0 team-wallet-api-platform
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug]: Dapp Connect - Triggering a dapp connection displays wrong screen and cannot connect.
6 participants