Background

PR #7289 fixed a deadlock in the dev engine caused by register_modules being a synchronous NAPI function that acquired a DashMap lock. When JavaScript hooks called back into Rust while the lock was held, it caused a deadlock.

Problem

Synchronous NAPI functions that access shared mutable state (DashMap, Mutex, etc.) can cause deadlocks when:

1. Rust holds a lock while calling JavaScript hooks
2. JS hooks call back into Rust (via NAPI binding)
3. That call tries to acquire the same/conflicting lock

Audit Results

The following sync NAPI functions access shared state and need review:

HIGH Risk

MEDIUM Risk

LOW Risk (monitor)

Resolution

For each sync NAPI function, one of two actions is needed:

Option A: Make it async

If the function accesses shared state that could be contended during JS hook execution:

#[napi]
#[allow(
  clippy::unused_async,
  clippy::allow_attributes,
  reason = "Lock acquisition. Making async to avoid blocking Node.js thread."
)]
pub async fn function_name(&self, ...) {
  // ...
}

Option B: Add SYNC-SAFE comment

If the function is safe to remain sync (e.g., only called during initialization, no lock contention possible):

#[napi]
// SYNC-SAFE: <reason why this won't cause deadlock>
pub fn function_name(&self, ...) {
  // ...
}

Tasks

• remove_client - HIGH priority refactor(dev): make removeClient async #7313
• register_plugins - MEDIUM priority
• emit_file - MEDIUM priority
• emit_chunk - MEDIUM priority
• get_module_info - LOW priority
• get_module_ids - LOW priority
• add_watch_file - LOW priority
• get_file_name - LOW priority

Related

• fix(dev): make register_modules async #7289 - Fixed register_modules deadlock