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

Bumps `@metamask/queued-request-controller` to fix queueing issue with
Chain Permission `wallet_switchEthereumChain` and
`wallet_addEthereumChain` when switching to a previously permitted chain
and with `wallet_addEthereumChain` not being enqueued when it still
should be.

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

## **Related issues**

Related: MetaMask/core#4846
Fixes: #28101
Fixes: #27977

## **Manual testing steps**

The easiest way to test this would be a combination of using the test
dapp and the following request to switch chains
```
await window.ethereum.request({
 "method": "wallet_switchEthereumChain",
 "params": [
  {
    chainId: "0x1"
  }
],
});
```

The behaviors you should see include:
**One dapp:**
* On a dapp permissioned for chain A and B, on chain A, queue up several
send transactions, then use wallet_switchEthereumChain to switch to
chain B. The send transactions should NOT get cleared immediately after
requesting the chain switch. Chain switch should NOT happen until the
previous approvals are approved/rejected.
* On a dapp permissioned for chain A and B, on chain A, queue up one
send transaction, then use wallet_switchEthereumChain to switch to chain
B, then queue up several more send transactions. Reject/approve the
first transaction. Afterwards, you should see chain B as the active
chain for the dapp, and all subsequent approvals cleared/rejected
automatically.
* On a dapp permissioned for ONLY chain A, on chain A, queue up one send
transaction, then use wallet_switchEthereumChain to switch to chain B,
then queue up several more send transactions. Reject/approve the first
transaction. Afterwards, you should an approval prompt for adding chain
B. If you approve it, the dapp should then be on chain B, with all
subsequent approvals cleared/rejected. If you disapprove it, you should
be prompted with the subsequent approvals.
* On a dapp permissioned for ONLY chain A, on chain A,
wallet_switchEthereumChain to switch to chain B, then queue up several
more send transactions. Reject/approve the first transaction.
Afterwards, you should an approval prompt for adding chain B. If you
approve it, the dapp should then be on chain B, with all subsequent
approvals cleared/rejected. If you disapprove it, you should be prompted
with the subsequent approvals.

**Two dapps:**
* On a dapp permissioned for chain A, on chain A, queue up several send
transactions, On a separate dapp permissioned for chain A and B, on
chain A, use wallet_switchEthereumChain to switch to chain B. The send
transactions should NOT get cleared immediately after requesting the
chain switch. Chain switch should NOT happen until the previous
approvals are approved/rejected.
* On a dapp permissioned for chain A and B, on chain A, queue up one
send transaction. On a separate dapp permissioned for chain A and B, on
chain A, use wallet_switchEthereumChain to switch to chain B. Then on
the first dapp queue up several more send transactions. Reject/approve
the first transaction. Afterwards, you should see chain B as the active
chain for the second dapp, and then you should still be prompted with
the subsequent approvals for the first dapp.
* One one dapp, start a wallet_addEthereumChain for a chain that does
not exist in the wallet and leave the approval alone. On a different
dapp, do the same thing. Only the request from the first dapp should be
accessible (i.e. no scrubbing between both of them). After rejecting the
first request, the second request should then appear (which will look
exactly the same of course). Wallet should not lock up if you repeat
this and accept either of the requests

## **Screenshots/Recordings**

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

### **Before**

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

### **After**


https://github.com/user-attachments/assets/2634119f-67db-4866-8520-9320a9400b1d



https://github.com/user-attachments/assets/c78c13ab-ea4f-4420-bccc-70959786e8db



## **Pre-merge author checklist**

- [ ] 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).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] 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.

---------

Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>

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

Bumps `@metamask/queued-request-controller` to fix queueing issue with
Chain Permission `wallet_switchEthereumChain` and
`wallet_addEthereumChain` when switching to a previously permitted chain
and with `wallet_addEthereumChain` not being enqueued when it still
should be.

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

Related: MetaMask/core#4846
Fixes: #28101
Fixes: #27977

The easiest way to test this would be a combination of using the test
dapp and the following request to switch chains
```
await window.ethereum.request({
 "method": "wallet_switchEthereumChain",
 "params": [
  {
    chainId: "0x1"
  }
],
});
```

The behaviors you should see include:
**One dapp:**
* On a dapp permissioned for chain A and B, on chain A, queue up several
send transactions, then use wallet_switchEthereumChain to switch to
chain B. The send transactions should NOT get cleared immediately after
requesting the chain switch. Chain switch should NOT happen until the
previous approvals are approved/rejected.
* On a dapp permissioned for chain A and B, on chain A, queue up one
send transaction, then use wallet_switchEthereumChain to switch to chain
B, then queue up several more send transactions. Reject/approve the
first transaction. Afterwards, you should see chain B as the active
chain for the dapp, and all subsequent approvals cleared/rejected
automatically.
* On a dapp permissioned for ONLY chain A, on chain A, queue up one send
transaction, then use wallet_switchEthereumChain to switch to chain B,
then queue up several more send transactions. Reject/approve the first
transaction. Afterwards, you should an approval prompt for adding chain
B. If you approve it, the dapp should then be on chain B, with all
subsequent approvals cleared/rejected. If you disapprove it, you should
be prompted with the subsequent approvals.
* On a dapp permissioned for ONLY chain A, on chain A,
wallet_switchEthereumChain to switch to chain B, then queue up several
more send transactions. Reject/approve the first transaction.
Afterwards, you should an approval prompt for adding chain B. If you
approve it, the dapp should then be on chain B, with all subsequent
approvals cleared/rejected. If you disapprove it, you should be prompted
with the subsequent approvals.

**Two dapps:**
* On a dapp permissioned for chain A, on chain A, queue up several send
transactions, On a separate dapp permissioned for chain A and B, on
chain A, use wallet_switchEthereumChain to switch to chain B. The send
transactions should NOT get cleared immediately after requesting the
chain switch. Chain switch should NOT happen until the previous
approvals are approved/rejected.
* On a dapp permissioned for chain A and B, on chain A, queue up one
send transaction. On a separate dapp permissioned for chain A and B, on
chain A, use wallet_switchEthereumChain to switch to chain B. Then on
the first dapp queue up several more send transactions. Reject/approve
the first transaction. Afterwards, you should see chain B as the active
chain for the second dapp, and then you should still be prompted with
the subsequent approvals for the first dapp.
* One one dapp, start a wallet_addEthereumChain for a chain that does
not exist in the wallet and leave the approval alone. On a different
dapp, do the same thing. Only the request from the first dapp should be
accessible (i.e. no scrubbing between both of them). After rejecting the
first request, the second request should then appear (which will look
exactly the same of course). Wallet should not lock up if you repeat
this and accept either of the requests

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

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

https://github.com/user-attachments/assets/2634119f-67db-4866-8520-9320a9400b1d

https://github.com/user-attachments/assets/c78c13ab-ea4f-4420-bccc-70959786e8db

- [ ] 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).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] 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.

---------

Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>

This is a cherry-pick of #28090 for v12.6.0. Original description:

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

Bumps `@metamask/queued-request-controller` to fix queueing issue with
Chain Permission `wallet_switchEthereumChain` and
`wallet_addEthereumChain` when switching to a previously permitted chain
and with `wallet_addEthereumChain` not being enqueued when it still
should be.

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

## **Related issues**

Related: MetaMask/core#4846
Fixes: #28101
Fixes: #27977
Fixes: #28102

## **Manual testing steps**

The easiest way to test this would be a combination of using the test
dapp and the following request to switch chains
```
await window.ethereum.request({
 "method": "wallet_switchEthereumChain",
 "params": [
  {
    chainId: "0x1"
  }
],
});
```

The behaviors you should see include:
**One dapp:**
* On a dapp permissioned for chain A and B, on chain A, queue up several
send transactions, then use wallet_switchEthereumChain to switch to
chain B. The send transactions should NOT get cleared immediately after
requesting the chain switch. Chain switch should NOT happen until the
previous approvals are approved/rejected.
* On a dapp permissioned for chain A and B, on chain A, queue up one
send transaction, then use wallet_switchEthereumChain to switch to chain
B, then queue up several more send transactions. Reject/approve the
first transaction. Afterwards, you should see chain B as the active
chain for the dapp, and all subsequent approvals cleared/rejected
automatically.
* On a dapp permissioned for ONLY chain A, on chain A, queue up one send
transaction, then use wallet_switchEthereumChain to switch to chain B,
then queue up several more send transactions. Reject/approve the first
transaction. Afterwards, you should an approval prompt for adding chain
B. If you approve it, the dapp should then be on chain B, with all
subsequent approvals cleared/rejected. If you disapprove it, you should
be prompted with the subsequent approvals.
* On a dapp permissioned for ONLY chain A, on chain A,
wallet_switchEthereumChain to switch to chain B, then queue up several
more send transactions. Reject/approve the first transaction.
Afterwards, you should an approval prompt for adding chain B. If you
approve it, the dapp should then be on chain B, with all subsequent
approvals cleared/rejected. If you disapprove it, you should be prompted
with the subsequent approvals.

**Two dapps:**
* On a dapp permissioned for chain A, on chain A, queue up several send
transactions, On a separate dapp permissioned for chain A and B, on
chain A, use wallet_switchEthereumChain to switch to chain B. The send
transactions should NOT get cleared immediately after requesting the
chain switch. Chain switch should NOT happen until the previous
approvals are approved/rejected.
* On a dapp permissioned for chain A and B, on chain A, queue up one
send transaction. On a separate dapp permissioned for chain A and B, on
chain A, use wallet_switchEthereumChain to switch to chain B. Then on
the first dapp queue up several more send transactions. Reject/approve
the first transaction. Afterwards, you should see chain B as the active
chain for the second dapp, and then you should still be prompted with
the subsequent approvals for the first dapp.
* One one dapp, start a wallet_addEthereumChain for a chain that does
not exist in the wallet and leave the approval alone. On a different
dapp, do the same thing. Only the request from the first dapp should be
accessible (i.e. no scrubbing between both of them). After rejecting the
first request, the second request should then appear (which will look
exactly the same of course). Wallet should not lock up if you repeat
this and accept either of the requests

## **Screenshots/Recordings**

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

### **Before**

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

### **After**


https://github.com/user-attachments/assets/2634119f-67db-4866-8520-9320a9400b1d



https://github.com/user-attachments/assets/c78c13ab-ea4f-4420-bccc-70959786e8db



## **Pre-merge author checklist**

- [ ] 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).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] 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.

---------

Co-authored-by: jiexi <jiexiluan@gmail.com>
Co-authored-by: MetaMask Bot <metamaskbot@users.noreply.github.com>

…s not updated after flushing requests for an origin (#4898)

## Explanation

Fix issue where `QueuedRequestController.state.queuedRequestCount` is
not updated after flushing requests for an origin

## References
- #4846
- MetaMask/metamask-extension#28090

## Fixes
- Bug identified [in v12.7.0 RC
Thread](https://consensys.slack.com/archives/C029JG63136/p1730918073046389?thread_ts=1729246801.516029&cid=C029JG63136)

## Before


https://drive.google.com/file/d/1ujdQgVLlT8KlwRwO-Cc3XvRHPrkpxIg_/view?usp=drive_link

## After


https://github.com/user-attachments/assets/e77928e5-165b-441a-b4da-0e10471c0529


## Changelog

### `@metamask/queued-request-controller`

- **FIX**: Ensure queuedRequestCount value is updated properly after
flushing the queue for a given origin

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

Bumps version of QueuedRequestController, with a patch that fixes an
issue where `QueuedRequestController.state.queuedRequestCount` is not
updated after flushing requests for an origin

## References
- MetaMask/core#4899
- MetaMask/core#4846
- #28090

## Fixes
Fixes #28358

[Slack discussion in v12.7.0 RC
Thread](https://consensys.slack.com/archives/C029JG63136/p1730918073046389?thread_ts=1729246801.516029&cid=C029JG63136)

## Before


https://drive.google.com/file/d/1ujdQgVLlT8KlwRwO-Cc3XvRHPrkpxIg_/view?usp=drive_link

## After


https://github.com/user-attachments/assets/e77928e5-165b-441a-b4da-0e10471c0529


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

## **Manual testing steps**

On a dapp permissioned for chain A and B, on chain A, queue up one send
transaction, then use wallet_switchEthereumChain to switch to chain B,
then queue up several more send transactions. Reject/approve the first
transaction. Afterwards, you should see chain B as the active chain for
the dapp, and all subsequent approvals cleared/rejected automatically.


- [ ] 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).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] 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.

## **Description**

Bumps version of QueuedRequestController, with a patch that fixes an
issue where `QueuedRequestController.state.queuedRequestCount` is not
updated after flushing requests for an origin

## References
- MetaMask/core#4899
- MetaMask/core#4846
- #28090

## Fixes
Fixes #28358

[Slack discussion in v12.7.0 RC
Thread](https://consensys.slack.com/archives/C029JG63136/p1730918073046389?thread_ts=1729246801.516029&cid=C029JG63136)

## Before


https://drive.google.com/file/d/1ujdQgVLlT8KlwRwO-Cc3XvRHPrkpxIg_/view?usp=drive_link

## After


https://github.com/user-attachments/assets/e77928e5-165b-441a-b4da-0e10471c0529


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

## **Manual testing steps**

On a dapp permissioned for chain A and B, on chain A, queue up one send
transaction, then use wallet_switchEthereumChain to switch to chain B,
then queue up several more send transactions. Reject/approve the first
transaction. Afterwards, you should see chain B as the active chain for
the dapp, and all subsequent approvals cleared/rejected automatically.


- [ ] 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).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] 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.

#28355) (#28371)

## **Description**

Bumps version of QueuedRequestController, with a patch that fixes an
issue where `QueuedRequestController.state.queuedRequestCount` is not
updated after flushing requests for an origin

## References
- MetaMask/core#4899
- MetaMask/core#4846
- #28090

## Fixes
Fixes #28358

[Slack discussion in v12.7.0 RC

Thread](https://consensys.slack.com/archives/C029JG63136/p1730918073046389?thread_ts=1729246801.516029&cid=C029JG63136)

## Before



https://drive.google.com/file/d/1ujdQgVLlT8KlwRwO-Cc3XvRHPrkpxIg_/view?usp=drive_link

## After



https://github.com/user-attachments/assets/e77928e5-165b-441a-b4da-0e10471c0529


[![Open in GitHub

Codespaces](https://github.com/codespaces/badge.svg)](https://codespaces.new/MetaMask/metamask-extension/pull/28355?quickstart=1)

## **Manual testing steps**

On a dapp permissioned for chain A and B, on chain A, queue up one send
transaction, then use wallet_switchEthereumChain to switch to chain B,
then queue up several more send transactions. Reject/approve the first
transaction. Afterwards, you should see chain B as the active chain for
the dapp, and all subsequent approvals cleared/rejected automatically.


- [ ] 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).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] 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.


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

<!--
Write a short description of the changes included in this pull request,
also include relevant motivation and context. Have in mind the following
questions:
1. What is the reason for the change?
2. What is the improvement/solution?
-->

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

## **Related issues**

Fixes:

## **Manual testing steps**

1. Go to this page...
2.
3.

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

- [ ] 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).
- [ ] I've completed the PR template to the best of my ability
- [ ] I’ve included tests if applicable
- [ ] 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.