TL;DR
Bug: Calling optimize() on a ZVec Collection that had recovered from an unclean process termination silently discarded the documents restored by WAL replay. The call raised no exception, and stats() on the same handle reported index_completeness: 1.0 — a false signal of success. The loss only became visible when the collection was reopened from a separate process.
Impact: In a minimal repro, doc_count regressed from 150 to 0 after optimize() on a crash-recovered collection with no prior flush() calls.
Fix latency: 54 hours 55 minutes from issue filing to merged fix (alibaba/zvec #594 → #600).
Root cause: A WAL handle lifecycle bug — segment recovery replayed the WAL into a local handle and closed it without reattaching it to the segment, so optimize() treated the writing segment as having no WAL records and skipped persisting the recovered data.
