Cross-tab transaction blocking

[wbt]

Describe the bug
A transaction pending from one browser tab is blocking transactions from another.

Detailed steps to observation:
I have a local private proof of authority chain running on Geth 1.9.10. In an effort to develop steps to reproduce for an unrelated issue, I have a "truffle migrate" running in the background which generates a very large number of very small transactions, one at a time in sequence, with one transaction per block that should only be using up a small percentage of the block gas limit and a small percentage of available bandwidth on the HTTP RPC provider.

I also have a dapp running on that chain, and an interface using Metamask. On one page of the dapp, I trigger one transaction. It remains Pending for a while. I click Speed Up => Fast and it still remains pending. I click to Speed Up again and manually set a gas price of 500 Gwei (it was around 140 before). It still remains pending, for a while.
In a different browser tab, I open the Dapp to a different page and trigger another transaction (which does happen to interact with the same contract) and give it a gas price of 600 Gwei from the start.

Actual behavior
The second transaction is in a Queued state, while the first remains Pending.

This condition continues for hours at least, as of when the issue is filed, even after the migration crashes out with an Invalid JSON RPC response: "" error.

The "Pending" transaction has a hash "0x9bdd186..." and the "Queued" transaction has hash "0x5ece345..."

In the Geth logs, I see the following, repeated many times, with gaps between sets alternating between about 1 and about 19 seconds, for a chain with a 5 second block time. The not-shown "t" parameter for each line is either 0s or approximately 997µs.

WARN Served eth_sendRawTransaction conn=127.0.0.1:50629 reqid=2965607936404 err="replacement transaction underpriced"
WARN Served eth_sendRawTransaction conn=127.0.0.1:50629 reqid=2965607936405 err="replacement transaction underpriced"
WARN Served eth_sendRawTransaction conn=127.0.0.1:50629 reqid=2965607936406 err="known transaction: 9bdd186..."
WARN Served eth_sendRawTransaction conn=127.0.0.1:50629 reqid=2965607936407err="known transaction: 5ece345..."

This does not end even after a long while. I click the Cancel button shown in the screenshot and accept the cancellation gas fee, but the transaction remains Pending:

The geth log continues as before, but now the "replacement transaction underpriced" errors are usually in triplicate. Even stopping Geth doesn't lead to any change in what MetaMask shows, including the word "Connected" in the upper left (meaning the account is visible to the dapp; MetaMask cannot be connected to the network because its endpoint has disappeared; the UI is misleading).

Cancelling the Queued transaction and accepting the cancellation gas fee, "Replacement transaction underpriced" starts showing up in sets of 4. Waiting a while, shutting down all Geth nodes, and restarting them, I still have that one transaction Pending and the other Queued, with no Cancel buttons. Changing to a different network and account, I can do transactions on that other network, but when coming back and reconnecting to the local network there is still no change.

Upon attempting to issue a new transaction (from a new tab), I can see in Geth the "Submitted transaction" line and I can see it showed up as Queued in MetaMask, but it's stuck there. It joins the other two in a "known transaction" error set in geth logs every so many seconds.

I try to cancel that and accept the gas fee; the Cancel button goes away. When I try Reset Account and accept the warning, the activity tab empties out as expected.

Only then can I submit transactions from the dapp and have them go through.

Expected behavior
The second transaction enters a Pending state similar to the first, or even better both reach the confirmed state pretty quickly. A cancelled transaction from one tab does not block transactions from other tabs. "Reset Account" is never required for restoring basic functionality of a dapp.

Browser details (please complete the following information):
Windows 10
Node 9.3.0, npm 6.14.5
geth 1.9.10
MetaMask Version 8.0.5

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

[wbt]

I don't think this should be closed without an improvement.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

[wbt]

I still don't think this should be closed without an improvement.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity in the last 90 days. It will be closed in 45 days if there is no further activity. The MetaMask team intends on reviewing this issue before close, and removing the stale label if it is still a bug. We welcome new comments on this issue. We do not intend on closing issues if they report bugs that are still reproducible. Thank you for your contributions.

[github-actions]

This issue was closed because there has been no follow up activity in the last 45 days. If you feel this was closed in error, please reopen and provide evidence on the latest release of the extension. Thank you for your contributions.

[wbt]

I still don't think this should have been closed without an improvement.