sebws

> If it was a typical leak, we'd have N number of workers across N hot updates, each with their own set of handlers. But that's not the case. The...

I followed your reproduction steps just now, but added `console.log(worker.listHandlers())` after the `worker.start()` call in `msw-provider`. I get just two handlers in both calls, however I still get the duplicate...

> you are viewing an old worker instance, even after HMR Seems like we’re saying the same thing then, because that’s what I’m saying. That you can see old handlers...

I'm having some luck :) It's another funny workaround/dodgy type of thing, however I added the following to `mockingEnabledPromise` after the call to `worker.start` ```js module.hot?.dispose(() => { worker.stop(); });...

Actually, looks like it's even better to just put `module.hot?.dispose(worker.stop)` into browser.ts :) Then it doesn't even require changing the suspense from `null` to `false` (although it's probably not the...

I was getting some odd issues with just worker.stop. Moving it to an arrow function `() => { worker.stop(); }` has prevented those issues and makes more sense at a...

Looks like it's still an issue in [email protected]

https://github.com/mswjs/examples/pull/101#issuecomment-2434780097 @kettanaito I think I have found why exactly `worker.stop()` is fixing the issue. The reason the old worker is being retained is because of the interval set on the...

tbh it might be a bit harder, given this wrapper already wraps incorrectly and doesn't support node-cron fully, e.g. string referring to a file instead of a callback. however, just...

maybe a different style of wrapper would be more accurate that passed through without manipulation and would add [event listeners](https://nodecron.com/event-listening.html), leaving node-cron to fully handle the execution. although I'm not...