Hi all, I’d like to share an improvement introduced by PR #18304:
https://github.com/apache/iotdb/pull/18304 This PR improves error reporting when a corrupted TsFile is encountered during query execution. Previously, the original IOException from the TsFile reader could be wrapped as a generic RuntimeException, without identifying the corrupted file. This made it difficult to locate and diagnose the problematic TsFile. This PR introduces `CorruptedTsFileException`, which preserves the corruption context, including the detection stage and, where appropriate, the TsFile path. Main improvements include: - Identify common corruption detection stages, such as reading metadata, loading chunks or pages, decoding page data, and reading metadata index nodes. - Return clearer errors for normal IoTDB queries, directing users to check server logs for details. - Return the full corrupted TsFile path for `read_tsfile` queries, helping users locate external damaged files directly. - Preserve the exception as a query-abort cause so the query engine can handle it consistently. - Add integration tests covering metadata-index and page-data corruption scenarios. This improvement is useful for troubleshooting corrupted TsFiles, especially when querying external files through `read_tsfile`, where users need to quickly identify the affected file. Feedback and suggestions are welcome. 大家好， 我想分享一个在 PR #18304 中引入的改进： https://github.com/apache/iotdb/pull/18304 该 PR 改进了查询执行过程中遇到损坏 TsFile 时的错误提示。 此前，TsFile 读取器抛出的原始 IOException 可能会被包装成不包含损坏文件信息的通用 RuntimeException，导致用户难以定位和排查问题文件。 该 PR 新增了 `CorruptedTsFileException`，用于保留 TsFile 损坏的上下文信息，包括发现问题的阶段，以及在适当情况下的 TsFile 路径。 主要改进包括： - 标识常见的损坏发现阶段，例如读取元数据、加载 Chunk 或 Page、解码 Page 数据、读取元数据索引节点等。 - 对普通 IoTDB 查询返回更清晰的错误信息，并提示用户查看服务端日志获取详细信息。 - 对 `read_tsfile` 查询返回完整的损坏 TsFile 路径，便于用户直接定位损坏的外部文件。 - 将该异常作为查询中止原因进行处理，使查询引擎能够一致地处理此类错误。 - 新增集成测试，覆盖元数据索引和 Page 数据损坏等场景。 该改进有助于排查损坏 TsFile，特别是在通过 `read_tsfile` 查询外部文件时，用户可以更快地定位受影响的文件。 欢迎大家提出反馈和建议。 Best regards, Wenwei Shu
