Debug ID: Considering splitting the proposal

[szuend]

The Debug ID proposal consists of 3 additions:

1. The "debugId" field in the source map JSON
2. The "debugId" magic comment in bundles
3. A runtime API to get the Debug ID of the currently running script as well as the debug id of each stack frame in a stack trace.

It might be worth it to consider landing 1) and 2) independent of 3).

Why?

In Chrome DevTools we recently landed an extension API that allows extensions to attach source mapping URLs to Resources. Or provide full source maps in the form of data URLs.

With 1) and 2) in-place, DevTools could add the "debugID" as reported by the engine on the "Resource" object and extensions could use that to then resolve/load the correct source map. The current proposal already goes in a similar direction in the section "Symbol Server Support".

My question from the DevTools sides are:

1. Does this solve an actual user problem?
2. Do we have implementors of symbol/artifact servers that would want this?

cc: @lforst @robpaveza

[lforst]

That's actually a pretty cool use case being able to view/debug the original source for production code via symbol servers without having to expose the sourcemaps somewhere.

Re the questions:

1. Looking a bit into the future, I believe it would solve an actual user problem because browser extension vendors using this API would pretty much immediately run into the same struggles as we do for source mapping URLs today. URLs are extremely flakey¹ for source map association, meaning that effectively every extension vendor/company (assuming it's mostly gonna be internal tools) will have to custom tailor their symbol servers to their specific setup/infrastructure, in addition to them probably constantly breaking due to infrastructure changes that aren't aligned with the extension. Having Debug IDs available to this API would allow for a solution that is "immune" to this flakiness.

2. I can only speak for Sentry right now, where I would say no, however, it would allow for the emergence of tooling that facilitates production debugging.

Footnotes

1. Factors contributing to flakiness are things like the location of bundles changing with infrastructure changes - think CDN URLs or reverse proxies that may change independently from the logic inside the extensions attaching source mapping URLs to Resources. From experience, setups can get quite complex. ↩

[lforst]

I asked internally at Sentry and got buy in to a) provide a symbol server that our customers can use to host their sourcemaps and b) build an extension that would make use of the symbol server to allow in-production DevTools. 👍 So Sentry would definitely be a party that would want this. The great thing is that we already have a lot of customers that upload their sources and sourcemaps with debug IDs to our servers, so we can validate rather quickly.

The only reservation would be that it is a bit dependent on the extension API that Chrome implements. We would like to avoid having to agree to a symbol server API. A strawman proposal for a Chrome Extension API that we could work with:

function registerDebugIdSourcemapResolver(debugId: string): Promise<SourceMap>;

A function like that would be flexible enough that we don't yet have to agree to a standardized symbol server format.

[szuend]

That is awesome to hear!

From a Chrome DevTools extension API point of view we'd like to stick with the existing API design. That is, an extension would listen to ResourceAdded events. We'd add the 'debugId' as a new property on the Resource type. And then the extension can provide the source map via attachSourceMapUrl. If the extension wants to provide the source map directly, it can do so as a data URL.

Would that be sufficient for a strawman extension?

The only bits that are currently missing on the Chrome side are:

1. Parse out the debugId field in V8
2. Pipe it through to DevTools and expose it on the Resource type

[lforst]

Would that be sufficient for a strawman extension?

I think that API is still expressive enough to work for our use case (admittedly, it adds complexity, but nothing we can't work around!).

A last dumb question to fully confirm: Since this API exists to grab sourcemaps behind authentication, the idea behind the API is to attach some sort of auth token to the resource URL via a query param or similar. Correct?

Do you want us to upstream this to v8 and DevTools, or are you planning on building it yourself? :) Maybe we can re-use some stuff from the Debug ID CL we prepared a while ago: https://chromium-review.googlesource.com/c/v8/v8/+/5979833

[szuend]

A last dumb question to fully confirm: Since this API exists to grab sourcemaps behind authentication, the idea behind the API is to attach some sort of auth token to the resource URL via a query param or similar. Correct?

No, the idea would be that if the actual URL is behind authentication the extension would fetch the source map by itself handling all the necessary auth stuff, and then hand DevTools the full source map as a data URL. If it turns out that passing source maps as a data URL is inefficient, we can consider adding a second method that passes the JSON directly.

Do you want us to upstream this to v8 and DevTools, or are you planning on building it yourself? :) Maybe we can re-use some stuff from the Debug ID CL we prepared a while ago: https://chromium-review.googlesource.com/c/v8/v8/+/5979833

We can probably take the parser bits but the rest needs to be passed through the inspector instead. I was planning to start implementation work next week :) But feel free to give it a go if you wanna take a stab at it yourself. You can basically follow the path of "sourceMappingUrl" and how it ends up in DevTools. There already exists a "buildId" field on the Debugger.scriptParsed method thats used for WASM at the moment that we can use for the debugId for JS.

[szuend]

To be clear, attaching an auth token as a query param and let DevTools do the fetch is also possible. Note however, that DevTools attempts to fetch the source map through the inspected page itself (it's nearly the same as typing fetch(<url>) into the console.

[lforst]

the extension would fetch the source map by itself handling all the necessary auth stuff, and then hand DevTools the full source map as a data URL

Ohhh that makes total sense. Nice. In that case, this will be quite easy for us to implement! I am glad I asked the dumb question.

I was planning to start implementation work next week :) But feel free to give it a go if you wanna take a stab at it yourself.

If you had planned to work on this already, please go ahead! I feel like you know your way around the v8 and dev tools code base way more than us. :) We can get the extension work started.

[lforst]

I will also prepare a PR to split the JS API stuff from the proposal.

[szuend]

The work on the V8 / Chrome DevTools side is tracked here: https://crbug.com/413177407. First CLs are in-flight and will hopefully land next week.

[szuend]

CLs landed, it's already shipping in V8 and the Chrome DevTools Protocol (CDP). The addition to the Chrome DevTools Extension API should be available in the next Chrome Canary or two.