quickwit-oss/tantivy · error

Managed file lock poisoned

Error message

Managed file lock poisoned

What it means

Fires in register_file_as_managed when taking the write lock on meta_informations to record a new managed file before it is created. The RwLock is poisoned — a previous holder panicked — so the managed-path registry cannot be safely updated and registration aborts. This is a poisoned-lock sentinel, not a problem with the file path itself; note that dot-prefixed paths (locks) skip this code entirely. Called from open_write and atomic_write, so the panic aborts writing/registering the file.

Source

Thrown at src/directory/managed_directory.rs:221

    ///
    /// This method must be called before the file is
    /// actually created to ensure that a failure between
    /// registering the filepath and creating the file
    /// will not lead to garbage files that will
    /// never get removed.
    ///
    /// File starting by "." are reserved to locks.
    /// They are not managed and cannot be subjected
    /// to garbage collection.
    fn register_file_as_managed(&self, filepath: &Path) -> io::Result<()> {
        // Files starting by "." (e.g. lock files) are not managed.
        if !is_managed(filepath) {
            return Ok(());
        }
        let mut meta_wlock = self
            .meta_informations
            .write()
            .expect("Managed file lock poisoned");
        let has_changed = meta_wlock.managed_paths.insert(filepath.to_owned());
        if !has_changed {
            return Ok(());
        }
        save_managed_paths(self.directory.as_ref(), &meta_wlock)?;
        // This is not the first file we add.
        // Therefore, we are sure that `.managed.json` has been already
        // properly created and we do not need to sync its parent directory.
        //
        // (It might seem like a nicer solution to create the managed_json on the
        // creation of the ManagedDirectory instance but it would actually
        // prevent the use of read-only directories..)
        let managed_file_definitely_already_exists = meta_wlock.managed_paths.len() > 1;
        if managed_file_definitely_already_exists {
            return Ok(());
        }
        self.directory.sync_directory()?;
        Ok(())

View on GitHub (pinned to b5d8deb80c)

Solutions

  1. Locate and fix the earlier panic that poisoned the meta_informations lock
  2. Avoid panics while holding the registry lock; return io::Error instead
  3. After recovery, re-open or rewrite the index so the managed file list stays consistent with on-disk files
Defensive patterns

Strategy: retry

When it happens

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