fix(rpc): stop multicall cache from replaying transient errors forever

[Danswar]

Incident

Since today ~09:05 UTC both monitoring instances (DEV and PRD) failed every 5-minute cycle with server response 500 Internal Server Error (RPC call failed after 4 attempts), counters climbing past 25 consecutive failures with no recovery. Position/challenge/collateral/minter/dEURO state sync was stale the whole time; event collection and the block cursor kept advancing.

Root cause

ethers-multicall-provider (6.5.0, latest) batches contract calls through a DataLoader created with cache: true. Two behaviors combine into a permanent-failure trap:

1. When an aggregate eth_call fails, the wrapper assigns the same Error instance to every call of the batch — and DataLoader explicitly caches Error results for individual keys.
2. The wrapper clears cache entries for latest-block calls only in a .then(onFulfilled) — i.e. only when the load succeeds. On rejection the poisoned entry stays forever.

So one transient HTTP 500 from the RPC provider poisons the cache keys (to+data+blockTag) of the whole batch. Every later identical call — including all withRetry attempts and every subsequent monitoring cycle — is served the original cached error without any RPC request being sent. Only a process restart recovers. This also explains why isConnectionError deliberately skipping provider recycling for 5xx ("the retry reaches the server anyway") did not help: the retry never reached the server.

Verified by replaying the production call set (98 positions, identical chunking/ABI/versions) against the same RPC endpoint — from a fresh process it succeeds every time, including from inside the failing container's own network; and a fail-once fake provider reproduces the permanent failure with cache: true and recovery with cache: false.

Fix

Pass cache = false to MulticallWrapper.wrap. Per-tick batching (the reason the wrapper is used) is unaffected; cross-cycle caching never existed on the success path anyway, because latest-block entries were cleared after each successful load. With the cache gone, withRetry genuinely re-sends the RPC and recovers from transient errors.

• jest moduleNameMapper for src/... imports added so the new spec (which imports ProviderService) resolves.
• Regression spec fails on the previous code (both tests) and passes with the fix.

Deploying

Rolling this out restarts the currently stuck instances, which also clears their poisoned in-memory caches.

[Danswar]

2 review passes until zero findings. Pass 1 flagged that the spec's intentionally failed first batch also dragged down the provider's lazy eth_chainId network detection (log noise plus a lingering 1s retry timer that could trigger jest's force-exit warning); fixed by completing the network bootstrap against the healthy fake before arming the failure. Pass 2 was clean. Verified along the way: the regression spec fails on the previous code with the exact incident symptom and passes with the fix, and the full suite runs green repeatedly with no warnings.