Intermittent connection pool exhaustion in Hardhat Network under concurrent JSON‑RPC load

Answer

The Hardhat Network node uses the default ethers JsonRpcProvider connection pool, which allows a maximum of 5 simultaneous HTTP connections. This pool size is not exposed in hardhat.config.js and cannot be changed via Hardhat configuration.

Confirmed facts

• Hardhat Network does not expose a configurable pool size; it inherits the ethers v5/v6 JsonRpcProvider default of 5.
• Enabling forking does not alter the pool size itself, but each JSON‑RPC request may trigger additional outbound calls to the upstream node, increasing the per‑request connection consumption.
• The only supported way to observe pool saturation is to turn on Hardhat’s internal debug logging (e.g., DEBUG=hardhat:network:* npx hardhat node) and look for messages such as “connection pool exhausted” or “waiting for available connection”.

Likely explanation

When forking is enabled, a single RPC call (e.g., eth_call) often results in the provider making extra HTTP requests to the remote upstream node to fetch state. Those extra requests draw from the same pool of 5 sockets, so the effective concurrency limit is reached sooner, producing intermittent timeouts or “connection pool exhausted” warnings.

Steps to verify

1. Start the Hardhat node with debug logging: DEBUG=hardhat:network:* npx hardhat node.
2. In a separate script, send a burst of JSON‑RPC requests in parallel (e.g., using Promise.all with 10‑20 eth_sendTransaction or eth_call calls).
3. Watch the console output; if the pool is exhausted you will see lines like “connection pool exhausted, waiting for available connection” before each request is processed.
4. Repeat the test with forking.enabled: true pointing to a local Ethereum node and note whether the exhaustion messages appear earlier or with higher latency.

To refine the recommendation, please share the approximate concurrency level (number of parallel JSON‑RPC calls) at which you begin to see exhaustion messages; that information determines whether raising the underlying provider’s maxSockets would be beneficial.