Unbounded eth_getLogs response causing memory strain in Hardhat Network

Question

Unbounded eth_getLogs response causing memory strain in Hardhat Network
The goal is to clarify whether Hardhat Network applies any automatic cap to the number of logs returned by a single eth_getLogs call when the requested block range contains hundreds of thousands of events, and to understand the impact on memory consumption during automated testing.
Hardhat’s documentation describes the method’s filtering parameters but does not mention a built‑in result‑size guardrail, and the project team has not yet decided on a default limit or a configurable option. Consequently, a query that spans a large range may attempt to return every matching log, potentially exhausting process memory and causing the node to hang or crash, while smaller ranges succeed without issue.
Does Hardhat Network currently return all matching logs without truncation? Is there a plan to introduce a configurable limit or a default cap for eth_getLogs? What block‑range size is advisable to keep memory usage within safe bounds for typical CI pipelines?

Tasadduq Burney · Answer

Answer
Hardhat Network does not apply any automatic result‑size limit to eth_getLogs. It returns every log that matches the filter, so memory usage grows linearly with the number of matching logs.
Confirmed facts

The Hardhat Network source (as of the latest public releases, e.g., Hardhat v2.19+) contains no constant such as MAX_LOGS or a result‑size check in the eth_getLogs handler.
  No configuration option is exposed to set a default or user‑defined cap on the number of logs returned.

Likely explanation
Because no cap is enforced, querying a block range that yields hundreds of thousands of logs can exhaust the CI container’s RAM, leading to OOM kills or prolonged test hangs. Discussions in the Hardhat repository show interest in adding a default or configurable guardrail, but no merged pull request or release note has implemented this feature yet.
Verification steps

Inspect the node module: grep -r "eth_getLogs" node_modules/hardhat/src/ and verify that the handler returns all matching logs without slicing or limiting the array.
  Create a test contract that emits a known number of logs per block (e.g., one log per block).
  Run eth_getLogs for a range of 5 000 blocks, monitor memory (Node’s --inspect or Docker stats), and confirm that memory usage scales proportionally and all logs are returned.
  Repeat with a 50 000‑block range; if memory spikes sharply or the process is killed, this confirms the lack of an automatic cap.

Practical recommendation
To keep memory usage safe in typical CI pipelines, limit the block range so that the expected total log count stays below a comfortable threshold (e.g., 5 000 logs). The safe range depends on the contract’s log density:

If the contract emits roughly one log per block, a range of 1 000–2 000 blocks usually yields < 2 000 logs.
  For higher‑frequency contracts, shrink the range proportionally (e.g., 10 logs/block → limit range to ~500 blocks).

Once you know the average logs per block for your contract, you can calculate the maximum range that keeps the expected log count under your chosen threshold.
Missing diagnostic detail
To refine the block‑range recommendation, please provide: What is the average number of logs emitted per block by the contract you are testing? This detail directly influences the safe range calculation.

Unbounded eth_getLogs response causing memory strain in Hardhat Network

Unbounded eth_getLogs response causing memory strain in Hardhat Network

1 answer

Answer

Confirmed facts

Likely explanation

Verification steps

Practical recommendation

Missing diagnostic detail

Your perspective belongs here.

0 question comments