quickwit-oss/tantivy · error

Managed directory wlock poisoned (2).

Error message

Managed directory wlock poisoned (2).

What it means

Fires in garbage_collect after deleting stale files, when re-acquiring the write lock on meta_informations to remove the deleted paths from the managed-file set. The lock is poisoned because some thread panicked while holding it, so the on-disk .managed.json state and the in-memory set may diverge. It is a poisoned-lock sentinel rather than an input validation error; the '(2)' distinguishes this second lock acquisition in the same method from the earlier read-lock panic.

Source

Thrown at src/directory/managed_directory.rs:187

                            failed_to_delete_files.push(file_to_delete.clone());
                            if !cfg!(target_os = "windows") {
                                // On windows, delete is expected to fail if the file
                                // is mmapped.
                                error!("Failed to delete {file_to_delete:?}");
                            }
                        }
                    }
                }
            }
        }

        if !deleted_files.is_empty() {
            // update the list of managed files by removing
            // the file that were removed.
            let mut meta_informations_wlock = self
                .meta_informations
                .write()
                .expect("Managed directory wlock poisoned (2).");
            let managed_paths_write = &mut meta_informations_wlock.managed_paths;
            for delete_file in &deleted_files {
                managed_paths_write.remove(delete_file);
            }
            self.directory.sync_directory()?;
            save_managed_paths(self.directory.as_mut(), &meta_informations_wlock)?;
        }

        Ok(GarbageCollectionResult {
            deleted_files,
            failed_to_delete_files,
        })
    }

    /// Registers a file as managed
    ///
    /// This method must be called before the file is
    /// actually created to ensure that a failure between

View on GitHub (pinned to b5d8deb80c)

Solutions

1. Fix the underlying panic that poisoned the meta_informations RwLock
2. Ensure save_managed_paths/sync_directory errors are propagated as Result instead of panicking under the lock
3. Re-run garbage collection after recovery so managed_paths is reconciled with deleted files

When it happens

Trigger: Thrown at src/directory/managed_directory.rs:187 when the library encounters an invalid state.

Common situations: See trigger scenarios.

AI-assisted analysis of quickwit-oss/tantivy@b5d8deb80c (2026-09-05). Data as JSON: /api/errors/44b70a0c4a032a67. Report an issue: GitHub.