The issue is "when dev engine is in the process of generating hmr update, a new file change will cause the nodejs hang during the second hmr update generating" In short, the hang is caused by deadlock. ## Details Rolldown stores the client information into `client` variable using `DashMap`, which is basically equivalent to `Mutex<HashMap>`. During the process of generating hmr update https://github.com/rolldown/rolldown/blob/5ef49ad615cfef1a9ebc97368546e1b9adbaf48d/crates/rolldown_dev/src/bundling_task.rs#L140 this line of code is equivalent to `client.lock()`, will means the lock of `client` will be hold during the whole generating process. The first hmr update is generated successfully and is sent to vite to trigger the hmr process. The browser loads the hmr patch and and sends message to vite node to register the new loaded module via code https://github.com/rolldown/rolldown/blob/0ce4a17c5ae1a95e331f8d38c5230742b09d1fd3/crates/rolldown_binding/src/binding_dev_engine.rs#L182-L184 nodejs calls `register_modules` https://github.com/rolldown/rolldown/blob/0ce4a17c5ae1a95e331f8d38c5230742b09d1fd3/crates/rolldown_binding/src/binding_dev_engine.rs#L183 This line of is also equivalent to `client.lock()`. In the meantime, dev engine is in the second hmr update generation, which holds the client lock already. So nodejs needs to wait for this lock to get free, and this wait is a **SYNCHRONOUS** wait. The nodejs itself doesn't have chance to resolve pending promises anymore(like resolving a timeout timer), while the hmr generating is awaiting js `transform` hook to be finished. All these things together cause a deadlock situation. --- If we have #7287 in the first place, it will be much easier to locate the problem, becuase we could easily find out which function is the last called function from `binding.js`. --- # Visual Explanation of the Deadlock ### The Circular Dependency ``` ┌──────────────────────────────────────────────────────────┐ │ │ ▼ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ │ Task 2 │ awaits │ Node.js │ waits │ Lock │ │ │ (Rust) │────────►│ transform │────────►│ (held by │───┘ │ │ │ hook │ SYNC │ Task 2) │ └────────────┘ └────────────┘ └────────────┘ │ ▲ │ │ │ register_modules │ │ called by browser │ │ (from Task 1's │ │ HMR patch) │ └──────────────────────┘ ``` ### Sequence of Events ``` 1. Task 1: Generate HMR #1 → Send to browser → Complete ✓ 2. File changes again → Task 2 starts 3. Task 2: Acquire clients lock 4. Task 2: Call JS transform hook (await) 5. Browser: Receives HMR #1, loads patch, calls register_modules 6. Node.js: register_modules tries to acquire lock (SYNC) 7. Node.js: BLOCKED waiting for lock (Task 2 has it) 8. Task 2: Waiting for JS promise to resolve 9. Node.js: Can't process promises (event loop blocked) 10. DEADLOCK! ``` ### The Fix Making `register_modules` async allows Node.js to **yield control** when waiting for the lock, keeping the event loop alive so it can resolve the transform hook promise. | Before (sync) | After (async) | |---------------|---------------| | Node.js **blocks entirely** waiting for lock | Node.js **yields** control back to event loop | | Event loop frozen, can't process callbacks | Event loop continues, can process transform callback | | **DEADLOCK** | **Works correctly** |

Track every #[napi] call using tracing crate #7287

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Track every `#[napi]` call using tracing crate #7287