quickwit-oss/tantivy · error

Managed directory rlock poisoned in garbage collect.

Error message

Managed directory rlock poisoned in garbage collect.

What it means

Fires in ManagedDirectory::garbage_collect when acquiring the read lock on meta_informations fails because the RwLock is poisoned — i.e. another thread panicked while holding the lock, leaving the managed-file set in an unknown state. It is a generic poisoned-lock sentinel (.expect on .read()), not a validation of file inputs; garbage collection cannot safely decide which files are deletable, so the panic aborts the GC run.

Source

Thrown at src/directory/managed_directory.rs:130

    ) -> crate::Result<GarbageCollectionResult> {
        debug!("Garbage collect");
        let mut files_to_delete = vec![];

        // It is crucial to get the living files after acquiring the
        // read lock of meta information. That way, we
        // avoid the following scenario.
        //
        // 1) we get the list of living files.
        // 2) someone creates a new file.
        // 3) we start garbage collection and remove this file
        // even though it is a living file.
        //
        // releasing the lock as .delete() will use it too.
        {
            let meta_informations_rlock = self
                .meta_informations
                .read()
                .expect("Managed directory rlock poisoned in garbage collect.");

            // The point of this second "file" lock is to enforce the following scenario
            // 1) process B tries to load a new set of searcher.
            // The list of segments is loaded
            // 2) writer change meta.json (for instance after a merge or a commit)
            // 3) gc kicks in.
            // 4) gc removes a file that was useful for process B, before process B opened it.
            match self.acquire_lock(&META_LOCK) {
                Ok(_meta_lock) => {
                    let living_files = get_living_files();
                    for managed_path in &meta_informations_rlock.managed_paths {
                        if !living_files.contains(managed_path) {
                            files_to_delete.push(managed_path.clone());
                        }
                    }
                }
                Err(err) => {
                    error!("Failed to acquire lock for GC");

View on GitHub (pinned to b5d8deb80c)

Solutions

1. Find and fix the original panic that poisoned the meta_informations lock (inspect earlier panic messages/logs)
2. Keep the GC critical sections free of panicking code (e.g. map IO errors instead of unwrapping)
3. Consider using lock recovery (into_inner / PoisonError handling) if tearing down the directory is preferable

When it happens

Trigger: Thrown at src/directory/managed_directory.rs:130 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/2f8509bca3dce21a. Report an issue: GitHub.