Is this blocking or can we come up with a better solution?

@roblourens: It is blocking our tests inside VS because the debugger errors out and exits if we send bak one response for multiple breakpoints inside the setBreakpoint request.
I think this is not a neat way to do this. We should probably come up with some internal breakpoint structure which we can return for these requests. Would you know if something like this exists in the protocol?
But to unblock our tests, I am fine with this fix temporarily until we come up with a better way to do it. Thoughts?

Why weren't the tests failing before?

We need to send unverified responses for the other breakpoints. There are a couple helpers for this in ChromeDebugAdapter. That might be happening with this fix automatically.

I think that pushing empty objects is probably the right solution. What should happen, is we hit this line later: https://github.com/Microsoft/vscode-chrome-debug-core/blob/master/src/chrome/chromeDebugAdapter.ts#L1358 and return unverified BPs for each.

I'll test this a little then take the PR.

Would be better if it's in the breakOnLoadHelper though

Oh and also it should not be returning the actual response from the break on load BP. That could make the first BP look like it was moved to line 1.

Done

Perfect!

Actually you should still await addStopOnEntryBreakpoint, right? I can add that.

Just published -core version 3.22.5

Please add it, I missed that..

I did, it's in that release.

Thanks :)