Indexer thread panics on malformed PDF instead of skipping it #15
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found during RAM-30 isolated breadmill testing. Confidence: high that the panic occurred (observed in stderr); medium on downstream impact. A manually started isolated breadmill (empty temp state/cache/config, default index roots) logged model-not-ready lines then died in an indexer thread: pdf-extract 0.10.0 src/lib.rs:1578 called Result::unwrap on Err(Parse(InvalidContentStream)) while handling a real user PDF. The panic message names thread unnamed and the process continued serving (socket stayed bound), so at minimum one indexing worker is lost and the file is never skipped cleanly. Expected: catch per-file extraction errors, log and skip the file, keep the worker alive. Reproduce: run breadmill with default roots over a tree containing a malformed PDF and watch stderr. The RAM-30 bench avoids this entirely with explicit empty index roots.