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

[dqh-au]

Actually, it's not quite as I described. The behaviour changes whether or not ANY breakpoint has been disabled via unticking in vscode, rather than deleted. In my previous tests I'd been disabling the 'magic breakpoint', but I have since found that there is nothing special about breaking just before invoking the dynamically imported code.

I'm actually importing and invoking 9 generated js files. I can make breakpoints concurrently set in all 9 files work 'reliably' IF:

1. No breakpoints are disabled; and
2. invocation of imported code is delayed using setTimeout(..., 100)

If I disable any breakpoint (without deleting it) then none will work.

If I don't delay at all, 1 or 2 randomish breakpoints will work. The number of breakpoints that work increases as I increase the delay. All 9 start to work on my dev machine at 4ms. By 'work' I mean that if I launch my process once, execution will pause at each of the 9 breakpoints, with me manually resuming after each breakpoint.

[connor4312]

This is generally the responsibility of the outFiles option; unlike browsers, Node.js (where I assume you're running) does not provide us a way to pause before a script with a sourcemap is evaluated. Therefore, we use the outFiles to scan the disk ahead of time for files with sourcemaps. I'm also guessing you're creating generate.js at runtime somehow, or it is outside your configured outFiles. In this case the debugger will parse the sourcemap and set any breakpoints that apply, but this may or may not before any relevant code is evaluated.

Collecting a trace log using the instructions in the issue template will provide more information.

[dqh-au]

I see. Yes - this is running under node 18, and I am generating generated.js* using rollup, and then executing that code to produce a static HTML file.

I have emailed you a log of a run with 9 enabled breakpoints, all in generated code, and without the call to setTimeout(). In this run, one breakpoint did trigger but I can't remember which one. Please let me know if you'd like any specific scenarios tested.

• not actually called 'generated.js', the file patten is '*-server.js' where * is one of 404, cookies, index, login, pricing-calculator, privacy, sign-up, terms.

[dqh-au]

It sounds like I should experiment with executing the generated code in a node subprocess and rely on vscode auto-attach, would you expect the race to be avoided with this approach?

[dqh-au]

(that does work nicely, based on initial testing. I'll rearchitect my build system to use this approach unless you can suggest a way to get deterministic breakpoint behaviour out of dynamically-generated-and-then-import()ed code)

[connor4312]

Yea, executing the generated code in a subprocess should work. New debug sessions--each child process is a new session--will run a targeted re-scan of files (though if you run into problems, you should try on the nightly build where scanning has been reworked and improved.)

[connor4312]

Though the 'proper' way to do this is with a prelaunch task that builds your code before starting to debug it. As a slight benefit, the generation will run a little faster if it's not under the debugger.

[dqh-au]

Thanks a lot for your help :) In my case I need to run the build system under the debugger, as I am actively developing a custom build system alongside the project itself. So I'll implement the final HTML generation phase as a single subprocess that executes each generated file and writes the output.

[connor4312]

👍 good luck in your project

[dqh-au]

Actually - perhaps there is still a bug here? While a race is understandable if node doesn't give you a way to block until the source map has been processed, why would disabling one breakpoint prevent all of them from working, no matter how long execution of imported code is delayed? (EDIT: sometimes)

[dqh-au]

For anyone coming across this situation in the future, while a node subprocess works, using a node 'Worker' is a much better developer experience. In particular, it's simpler to pass data to the worker code, simpler to get the output, and all worker threads within a node process share a single debug console within vscode.