Unbounded eth_getLogs response causing memory strain in Hardhat Network

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?