use preview build #27430
use preview build #27430
Conversation
|
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. |
|
New and removed dependencies detected. Learn more about Socket for GitHub ↗︎
🚮 Removed packages: npm/@metamask/[email protected] |
|
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎ To accept the risk, merge this PR and you will not be notified again.
Next stepsWhat is new author?A new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package. Scrutinize new collaborator additions to packages because they now have the ability to publish code into your dependency tree. Packages should avoid frequent or unnecessary additions or changes to publishing rights. What is network access?This module accesses the network. Packages should remove all network access that is functionally unnecessary. Consumers should audit network access to ensure legitimate use. What is a deprecated package?The maintainer of the package marked it as deprecated. This could indicate that a single version should not be used, or that the package is no longer maintained and any new vulnerabilities will not be fixed. Research the state of the package and determine if there are non-deprecated versions that can be used, or if it should be replaced with a new, supported solution. Take a deeper look at the dependencyTake a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev. Remove the packageIf you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency. Mark a package as acceptable riskTo ignore an alert, reply with a comment starting with
|
|
Seems right to me |
## Explanation The `QueuedRequestController` previously batched and processed requests based solely on their `origin`. This approach doesn't account for scenarios where a dapp interacts with multiple networks simultaneously from the same origin as will be the case on the multichain API. This PR updates the `QueuedRequestController` to batch and process requests based on both `origin` and `networkClientId`. This ensures that: - Requests from the same origin but targeting different networks are processed in separate batches. - Network switches occur appropriately between batches when the `networkClientId` changes. - Each request is processed on the correct network. Key changes: - **Batching Logic**: Modified the batching mechanism to consider both `origin` and `networkClientId`, for the legacy API this shouldn't change anything, but it allows us to cleanly batch for the multichain API until we remove queueing altogther. - **Request Validation**: Added validation to throw an error if a request doesn't include a `networkClientId`. - **Dependency Removal**: Removed reliance on `SelectedNetworkController` for determining `networkClientId`. Now `NetworkClientId` is expected on every request. Which should always be the case if the middleware ordering is correct on both APIs. - **Test Enhancements**: Added and updated tests to cover new scenarios involving multiple `origin`s and `networkClientId`s. Draft PR/Branch off caip-multichain feature branch with preview build: MetaMask/metamask-extension#27408 ## Videos demonstrating functionality w/ multichain API: ### 2 requests same network different dapps: https://github.com/user-attachments/assets/b7087322-093b-4229-86f9-d643540a5f5e ### 2 requests different network same dapp https://github.com/user-attachments/assets/80b9e820-30fd-4bd7-a82e-588243fa3a44 ### 2 requests same network same dapp https://github.com/user-attachments/assets/91e2e35d-2ab6-4863-a9e4-0b955815354e ### More complex flows: https://drive.google.com/file/d/1PvCmmCQbxXqglsFLUlyT_7P_znukLUxI/view?usp=drive_link https://drive.google.com/file/d/18R8zEPz_zsfhsw-DOkRFwkYRI1URynis/view?usp=sharing ### Queueing working same as before on legacy API [Branch/PR with preview builds on develop used to test ](MetaMask/metamask-extension#27430) https://github.com/user-attachments/assets/485d0a28-7075-4c65-be4b-b9022b6ef28f ## References - N/A ## Changelog ### `@metamask/queued-request-controller` - **CHANGED**: Batch processing now considers both `origin` and `networkClientId`, ensuring requests targeting different networks are processed separately. - **REMOVED**: Dependency on `SelectedNetworkController`; the controller no longer uses `SelectedNetworkController:getNetworkClientIdForDomain`. - **CHANGED**: Incoming requests to `enqueueRequest` now **must** include a `networkClientId`; an error is thrown if it's missing. This was previously a [required part of the type](https://github.com/MetaMask/core/blob/66c94ae4f0a54764ca890c927ffdbe3c2d6cd846/packages/queued-request-controller/src/types.ts#L5) but since consumers like the extension do not have extensive typescript coverage this isn't definitively enforced. ## 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 - [ ] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes
Description
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist