Skip to content

Unify the mutex lock-poisoning policy #383

Description

@AprilNEA

Lock-poisoning tolerance is scattered across 5 crates and 12+ sites with inconsistent behavior — some log (orchestrator.rs:452 documents its unwrap_or_else(PoisonError::into_inner)), some are fully silent. Worst case: agent-core/src/hook_runtime.rs (~161, also 149/194/288) does hooks.read().ok() — after a panic while holding the lock, every button binding silently stops working for the life of the agent.

Options, in preference order:

  1. parking_lot (no poisoning semantics, already in the dependency graph via gpui) — also lighter in the hook's hot path. Watch the gpui/gpui-component lock pins when adding the direct dependency.
  2. A single shared helper encoding one policy (PoisonError::into_inner + one warn), replacing all ad-hoc sites.

Surfaced by the standards audit behind #381.

Metadata

Metadata

Assignees

No one assigned

    Labels

    type: enhancementImprovement to existing functionality

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions