What is the recommended way to combine lazyCompilation/HMR with watching.suspend() / resume()?

[EnasAbdelrazek]

Context
We embed Rspack inside a desktop IDE. The IDE generates source files on disk. To avoid partial rebuilds while the IDE is still writing, we use watching.suspend() / watching.resume() gated by a stdin/stdout protocol: the IDE sends a resume command when it's done writing, the bundler compiles and reports back, then suspended until the next batch.

This works well in plain watch mode. We recently added @rspack/dev-server with HMR and lazy compilation on top of this suspend/resume flow, so users don't need a full page reload after each rebuild.

Current LazyCompilation Trial
A lazy compilation request can arrive while the watcher is suspended. We currently detect the lazy compilation trigger in setupMiddlewares() and resume the watcher before passing the request to Rspack's lazy compilation middleware:

if (isSuspended && req.url?.startsWith(lazyTriggerPrefix)) { 
  isSuspended = false; 
  devServer.middleware.context.watching.resume();
} 
lazyMiddleware(req, res, next);

we are trying to suspend the watcher again from the done hook:

compiler.hooks.done.tap("mx-rspack-runner", (stats) => {
    handleCompilerStats(stats);

    isSuspended = true;
    devServer.middleware.context.watching.suspend();

});

Problem

This seems to suspend the watcher before the browser has finished processing the HMR update, which results in HMR manifest requests returning 404.
I see the browser requesting HMR manifest files that are stale or invalid files.

Questions

• What is the recommended way to combine lazyCompilation/HMR with watching.suspend() / watching.resume()?
• Is there a supported Rspack/DevServer signal or API that the Node.js process can use to determine that the browser has finished receiving and applying the HMR update for a specific compilation triggered by a lazy-compilation request?

The main goal is to keep the watcher suspended while our IDE is writing files, while still allowing lazy compilation and HMR to complete correctly before suspending the watcher again.

[ChangkeunJ]

done only confirms compilation. In the browser, import.meta.webpackHot.addStatusHandler can observe apply followed by idle. Send the runtime hash back to Node and match the target build; idle alone doesn't prove an update was applied. Treat abort/fail as failures. This doesn't diagnose the 404.