matanper opened a new issue, #70405: URL: https://github.com/apache/doris/issues/70405
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Version 4.1.4. master (`14fde1c1dc0`) is the same: `be/src/storage/index/inverted/clucene/inverted_index_searcher.cpp:37-40`. ### Description `FulltextIndexSearcherBuilder::build` catches the `CLuceneError` thrown by `IndexReader::open` and then lists the directory to log its files, with no guard of its own: ```cpp } catch (const CLuceneError& e) { std::vector<std::string> file_names; directory->list(&file_names); // may throw LOG(ERROR) << fmt::format("Directory list: {}", fmt::join(file_names, ", ")); std::string msg = "FulltextIndexSearcherBuilder build error: " + std::string(e.what()); if (e.number() == CL_ERR_EmptyIndexSegment) { return Status::Error<ErrorCode::INVERTED_INDEX_FILE_CORRUPTED>(msg); } return Status::Error<ErrorCode::INVERTED_INDEX_CLUCENE_ERROR>(msg); } ``` The open usually fails because a storage read failed: a remote read error, a missing file, or a corrupt or empty segment. The same underlying problem often makes `directory->list()` fail too, and then a second `CLuceneError` escapes from the catch block. The caller sees the listing error instead of the original open failure, and the original handling is skipped: - the `CL_ERR_EmptyIndexSegment` → `INVERTED_INDEX_FILE_CORRUPTED` mapping; - the message carrying `e.what()` of the real failure. So an index that is corrupted, or that failed on a storage read, is reported as a generic directory-listing error. That makes the cause hard to diagnose, and it can change how callers treat the failure. ### Solution Treat the listing as best-effort diagnostics: wrap `directory->list()` in its own `try`/`catch (const CLuceneError&)`, log the listing failure, and keep building the `Status` from the original exception `e`. Results and error codes are unchanged whenever the listing succeeds. ### How to Reproduce? Make `IndexReader::open` fail on a storage read, for example with a fault injected into the index file reader (the existing `DorisFSDirectory::FSIndexInput::readInternal_reader_read_at_error` debug point) together with a failing directory listing. Or use a unit test with a `Directory` whose `openInput` and `list` both throw. The returned error is the listing failure, not the original open error, and `INVERTED_INDEX_FILE_CORRUPTED` is never returned for an empty segment in that case. ### Anything Else? We have a patch with a unit test (a directory whose `list()` throws after `open` fails; the test asserts the original error code and message are returned). ### Are you willing to submit PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
