ClickHouse DB::Exception: Attempt to read after EOF

The "DB::Exception: Attempt to read after EOF" error indicates that ClickHouse attempted to read more data from a stream or file after the end-of-file marker had already been reached. The ATTEMPT_TO_READ_AFTER_EOF error code is a low-level signal -- it means the parser or protocol handler tried to pull additional bytes from a source that had already been fully consumed. Unlike UNEXPECTED_END_OF_FILE which fires during initial parsing, this error often points to a deeper issue with data integrity or protocol handling.

Impact

This error causes the current operation to abort:

INSERT statements fail and no data is written.
SELECT queries reading from external files or remote sources will return an error instead of results.
In distributed setups, it can indicate a protocol-level communication failure between nodes.
If this error occurs during replication or merges, it may signal data part corruption.

Common Causes

Truncated data parts on disk -- a data file in the ClickHouse storage directory was corrupted or truncated, and the merge or read operation attempts to consume data beyond what is available.
Protocol-level data corruption -- when communicating between ClickHouse nodes (distributed queries, replication), a network issue causes the receiving side to get fewer bytes than expected.
Truncated input files -- reading from a local file or S3 object that was incompletely written.
Compressed data corruption -- a compressed block is shorter than its header claims, so decompression finishes early and the subsequent read attempt fails.
Client-server version mismatch -- different ClickHouse versions may have subtle protocol differences that cause one side to expect more data than the other sends.
Corrupted backup files -- restoring from a backup where some files were damaged during transfer or storage.

Troubleshooting and Resolution Steps

Check if the error occurs during INSERT or SELECT. An INSERT-time error usually points to bad input data. A SELECT-time error (especially one referencing a specific data part) points to on-disk corruption.

For on-disk corruption, identify the affected part:

SELECT name, active, rows, bytes_on_disk
FROM system.parts
WHERE table = 'my_table' AND database = 'my_db'
ORDER BY modification_time DESC
LIMIT 20;

Verify data part checksums:
```
CHECK TABLE my_db.my_table;
```
This will report any parts with checksum mismatches.

For a corrupted part, detach and re-fetch it (on replicated tables):

ALTER TABLE my_db.my_table DETACH PART 'all_0_0_0';
-- ClickHouse will re-fetch the part from another replica automatically

For input file issues, validate the file outside of ClickHouse:
```
wc -c /path/to/data.bin
# Compare against expected size
```

Check for network issues between nodes. Look at system.errors and system.replication_queue for patterns:

SELECT name, value, last_error_time, last_error_message
FROM system.errors
WHERE name LIKE '%EOF%' OR name LIKE '%read%'
ORDER BY last_error_time DESC;

Verify version compatibility if the error occurs during distributed queries. Ensure all nodes in the cluster are running compatible ClickHouse versions.

Best Practices

Run CHECK TABLE periodically on critical tables to detect silent data corruption early.
Use replicated tables (ReplicatedMergeTree) so that corrupted parts can be automatically re-fetched from healthy replicas.
Monitor disk health (SMART data, filesystem errors) on ClickHouse nodes since most on-disk corruption originates from hardware issues.
Keep all ClickHouse nodes in a cluster on the same version to avoid protocol incompatibilities.
When restoring from backups, always verify checksums before starting the restore.

Frequently Asked Questions

Q: What is the difference between ATTEMPT_TO_READ_AFTER_EOF and UNEXPECTED_END_OF_FILE?
A: UNEXPECTED_END_OF_FILE fires when the parser encounters EOF while still expecting more structured data (e.g., more rows, more fields). ATTEMPT_TO_READ_AFTER_EOF fires at a lower level -- the stream is already at EOF and something tries to read from it again. The latter is more commonly associated with data-part corruption or protocol issues.

Q: Can this error occur during normal queries on a healthy cluster?
A: It is unusual on a healthy cluster. If you see it during normal SELECT queries, it strongly suggests data corruption, a disk issue, or a network problem between cluster nodes.

Q: My replicated table shows this error for a specific part. Will ClickHouse fix it automatically?
A: If you detach the corrupted part, ClickHouse will attempt to re-fetch it from another replica. If the part exists on at least one healthy replica, recovery is automatic. If all replicas have the corrupt version, you will need to restore from backup.

Q: I see this error when reading Parquet files from S3. What should I check?
A: Verify that the Parquet file was fully uploaded to S3. Incomplete multipart uploads can leave truncated objects. Also check that no concurrent process is overwriting the file while ClickHouse reads it.