{"record":{"id":"ee721a4c6a0eec9d","repo":"zellij-org/zellij","slug":"cannot-acquire-poisoned-lock","errorCode":null,"errorMessage":"cannot acquire poisoned lock","messagePattern":"cannot acquire poisoned lock","errorType":"exception","errorClass":null,"httpStatus":null,"severity":"error","filePath":"zellij-utils/src/errors.rs","lineNumber":988,"sourceCode":"                        .with_context(|| context.to_string())\n                    } else {\n                        Err(anyhow::anyhow!(\"failed to send message to channel\"))\n                            .with_context(|| context.to_string())\n                    }\n                },\n            }\n        }\n    }\n\n    impl<U> ToAnyhow<U> for Result<U, std::sync::PoisonError<U>> {\n        fn to_anyhow(self) -> anyhow::Result<U> {\n            match self {\n                Ok(val) => anyhow::Ok(val),\n                Err(e) => {\n                    if *crate::consts::DEBUG_MODE.get().unwrap_or(&true) {\n                        Err(anyhow::anyhow!(\"cannot acquire poisoned lock for {e:#?}\"))\n                    } else {\n                        Err(anyhow::anyhow!(\"cannot acquire poisoned lock\"))\n                    }\n                },\n            }\n        }\n    }\n}\n","sourceCodeStart":970,"sourceCodeEnd":995,"githubUrl":"https://github.com/zellij-org/zellij/blob/bf8d23a4f774abf27a108da2a1a2689e7d8d0d23/zellij-utils/src/errors.rs#L970-L995","documentation":"The non-DEBUG_MODE variant of the PoisonError ToAnyhow impl in zellij-utils/src/errors.rs: acquiring a std::sync::Mutex failed because a previous thread panicked while holding it, and the PoisonError details are suppressed in production builds. Like the debug variant it is a downstream symptom of an earlier panic in a critical section.","triggerScenarios":".lock().to_anyhow() (or the codebase's ToAnyhow combinators around it) on a mutex already flagged poisoned by an earlier panic in another thread, with DEBUG_MODE disabled so only the generic message appears.","commonSituations":"Production/default builds where a worker thread panicked and the session subsequently deadlocks or errors on every shared-state access; users see frozen UI and this message in logs.","solutions":["Enable DEBUG_MODE and reproduce to get variant [70] plus richer panic output.","Kill the wedged session (zellij kill-session) and start fresh; in-process recovery from poisoning is not attempted.","Report the ORIGINAL panic (first backtrace in the log) upstream with steps to reproduce.","Update zellij."],"exampleFix":null,"handlingStrategy":"fallback","validationCode":null,"typeGuard":null,"tryCatchPattern":"// non-debug build: same recovery decision, message is generic\nlet guard = mutex.lock().unwrap_or_else(|poisoned| {\n    log::error!(\"lock poisoned (earlier panic elsewhere); continuing with recovered state\");\n    poisoned.into_inner()\n});","preventionTips":["Reproduce with DEBUG_MODE enabled to see the PoisonError detail of variant [70] and locate the poisoning thread.","Keep panics out of locked regions so poisoning cannot occur in the first place.","Consider parking_lot locks (no poisoning) in your own daemons, or catch_unwind around risky critical sections."],"tags":["zellij","rust","mutex","poisoned-lock","panic"],"backgroundTag":"mutex-poisoned","analyzedSha":"bf8d23a4f774abf27a108da2a1a2689e7d8d0d23","analyzedAt":"2026-08-19T07:42:58.758Z","contentChangedAt":"2026-08-19T07:42:58.758Z","schemaVersion":2},"datasetVersion":"2026-09-14T05:17:10.506Z"}