Possible race condition in source mapping / breakpoint binding within dynamic imports

[dqh-au]

EDIT: I have a simpler way to trigger this behaviour, see following comment

I have a breakpoint inside dynamically import()ed code that sometimes works. I can reliably make it work, or not, by enabling or disabling an entirely different breakpoint.

It does not work if the imported-file-breakpoint is the only breakpoint enabled. It does work if I also set a breakpoint in the importing code, just before I invoke the imported code with the breakpoint in it.

Complicating matters, the imported code has been generated and contains an inline source map pointing to a project file that at that point, has not been loaded by the runtime.

The code looks something like the following:

const data = { ... }
import('generated.js')
    .then(
        (module) =>
        {
            fs.writeFile('output.html', module.default(data)); // magic breakpoint needs to go on this line
        });

If I place a breakpoint on the fs.writeFile line, then a breakpoint inside the file that was transpiled to 'generated.js' will work, breaking execution within the call to module.default(data). However it does not work if the breakpoint on fs.writeFile is removed or disabled.

I can generate and send trace logs, please let me know you want them.

If this is expected behaviour, is there a programatic way I can force node and the vscode js debugger to get in sync?

Version: 1.74.2 (Universal) Commit: e8a3071ea4344d9d48ef8a4df2c097372b0c5161 Date: 2022-12-20T10:26:09.430Z Electron: 19.1.8 Chromium: 102.0.5005.167 Node.js: 16.14.2 V8: 10.2.154.15-electron.0 OS: Darwin arm64 22.2.0 Sandboxed: No