# eth_getLogs client response cases

Use these [35 synthetic cases](/examples/getlogs-guide-cases.jsonl) with a mock transport to check the clients in the [block-range guide](/en/guides/getlogs-block-range/). The cases and this documentation are available under the [MIT license](/examples/getlogs-client-cases.LICENSE).

Each JSON line contains:

- `input.catalog_http_status` and `input.max_logs_block_range`: the mock chain-catalog response.
- `input.scan_configuration`: the chain, method, address, inclusive scan range and numeric request ID for the test. This is test configuration, not a JSON-RPC wire request.
- `input.scripted_rpc_responses`: HTTP status and JSON bodies returned by the mock transport in order.
- `expected`: final success, exact requested ranges, accepted chunk count and language-specific output.

The cases cover successful empty and nonempty results, catalog/HTTP failures, invalid range limits, response versions and IDs, result types, responses containing an `error` member, and rejection after an earlier successful chunk. The example chain limits and address are synthetic test inputs.

## Run with a mock transport

1. Load one line. Set the fake catalog response and scan configuration from `input`.
2. Return each scripted HTTP status and body for the next RPC request. Do not send these fixture configurations to a live endpoint.
3. Record inclusive request ranges, accepted chunks, output and final success. Compare with `expected`. A catalog failure should issue no RPC request; a rejected chunk should stop the scan before later queue entries are consumed.
4. Compare JavaScript output with `javascript_chunk_outputs`. For the longer TypeScript/Python examples, compare normalized output digits with `typescript_python_stdout_digits`; this field is not literal terminal text. JavaScript can retain earlier chunk output when a later chunk fails, while the longer examples print the aggregate only when the scan succeeds.

A successful empty array is valid. A response must match the numeric request ID and expected array result, and must not contain an `error` member, before the client accepts the chunk. An error-only JSON-RPC response can be a valid error response while still rejecting that chunk.

These fixtures exercise client response handling and range advancement. They do not check individual log fields, event completeness, finality, reorgs or durable database commits.