MM, Trust wallets: the app gets disconnected

[elena-zh]

Reported in https://nomevlabs.slack.com/archives/C0361CDG8GP/p1773314859040969

Another similar case with Trust wallet: https://nomevlabs.slack.com/archives/C036G0J90BU/p1775232272277889

To reproduce:

1. connect to MM
2. start placing orders (like I did here https://dev.explorer.cow.fi/address/0x494721305c8947532e9d2860f2cf5ed79f76ab5f) or switching networks
3. in about 305 minutes, you will become rate limited and disconnected after connection.
4. tried to record a video, so please start watching from 45 sec https://www.loom.com/share/2231e5858de346cbb41cecd088056a25

Expected: the connection should not be reset.

[minato32]

Hey @elena-zh , I've been looking into this issue and I have found couple of things (used to AI format this)

The app constantly makes RPC calls through MetaMask's provider in the background, and over time these pile up enough to hit MetaMask's rate limiter, which ends up disconnecting the wallet.

There are three things polling non-stop:

• Block subscription (BlockNumberProvider) — fires every ~12s through MetaMask's provider
• Native token balance (useNativeTokenBalance) — SWR polling every 11s with no pause mechanism at all
• BFF balances — SWR polling every 8s, and there's also a bug here where event listeners get registered over and over because initializeFocusListeners() is called on every isPaused() invocation with anonymous arrow functions

Also useIsWindowVisible only checks the Page Visibility API (document.visibilityState), which still reports 'visible' when the user clicks to a different window without switching browser tabs. So if someone has CoW Swap open in one window while working in another app, all the polling keeps firing.

I'm thinking of implementing these :

1 — Stop polling when the window is not in focus

Add a useHasFocus hook to @cowprotocol/common-hooks that tracks actual window focus/blur events (not just tab visibility). Then BlockNumberProvider would require both windowVisible && hasFocus before subscribing to blocks. Same idea for the SWR hooks — pause them when the document doesn't have focus.
Also fix the listener accumulation bug in the BFF config with a simple initialization guard.

2 — Fall back to dedicated RPC if MetaMask stalls

Even with throttling, MetaMask could still get rate-limited during active use or if something else is hammering it. So I'd add a 60-second watchdog to BlockNumberProvider — if no block event comes in for ~5 missed Ethereum blocks, it automatically switches the subscription from the wallet provider to getRpcProvider(chainId) The initial getBlockNumber() call would also retry with the fallback on error. This way the app stays functional even if MetaMask goes silent.

Some trade off's to consider

	Throttling (Part 1)	RPC Fallback (Part 2)
Solves	Prevents rate-limiting from idle/unfocused windows	Keeps the app working if MetaMask stalls anyway
Downside	Balances/blocks won't update while unfocused — user sees brief stale state when they return	Adds some complexity to the block subscription logic; fallback uses the app's Infura key which has its own (higher) limits
Edge case	Doesn't help if the user is actively using the app in a focused window — polling still goes through MetaMask at full rate	Up to 60s of no block updates before the fallback kicks in

Worth considering longer term

Block numbers are chain-level data — they don't actually need to go through MetaMask at all. A cleaner long-term approach would be to route block polling through getRpcProvider() by default and reserve MetaMask's provider only for wallet-specific operations like signing and sending transactions. That would eliminate the rate-limiting issue at the root. The fix I'm proposing here takes the safer route to avoid changing the primary provider path in one go. Also if you have some quota limit on rpc provider this fix would help there as well.

Would you like me to go ahead and implement this?

[minato32]

@elena-zh hey did you have a chance to look into the suggestion i have provided ? please do let me know what you think. 😄

[kernelwhisperer]

I think no to Stop polling when the window is not in focus and yes to Fall back to dedicated RPC if MetaMask stalls but I don't agree to "So I'd add a 60-second watchdog to BlockNumberProvider — if no block event comes in for ~5 missed Ethereum block"

Probably we want to add fallback to the approve/swap flows (after something like 1-2-3 retries), to use our own RPC, but beware: If you're going to videcode it and propose a huge diff I will not review it 😅.

[minato32]

@kernelwhisperer okay, I will focus on a retry-based fallback (1-2-3 attempts) to a dedicated RPC for the approve/swap flows.
Will keep the diff small and scoped, no AI slop, only carefully hand-written slop 😅