Rethink where to put `debug_id` in event Payload

[lforst]

There are considerations around whether the location we currently have debug_id under is a good location. It is now located under event.exception.values[].stacktrace.frames[].debug_id. While it is currently not used, there are worries (mainly by @mitsuhiko and @jan-auer) that having a JavaScript-specific field in the stack frame protocol will complicate many things in our code base.

As of now, the better alternative seems to be putting the debug_id mappings inside the Debug Meta Interface. Here we would have an image type that maps from abs_path (of the JS source file) to debug_id (an identifier for the source map in the backend). Develop PR for more context.

There is a potential issue we may face down the line:

There is a good chance that the filename of a stack frame and the source_filename value of the Debug Meta mapping will not match, especially since we provide a dedicated API with the RewriteFrames integration to manipulate the file path in order to match source maps in the cases where the path may be dynamic. Essentially this means using the new debug_id approach alongside the RewriteFrames integration will in many cases not work.

The alternative solution is to keep the debug_id inside the stack frame object, completely disassociating the filename from source map resolving.

[AbhiPrasad]

that having a JavaScript-specific field in the stack frame protocol will complicate many things in our code base.

What is JavaScript specific about this protocol atm? It's just a uuid on the frame. It's open ended enough that it can be taken advantage of in other platforms as well!

[lforst]

that having a JavaScript-specific field in the stack frame protocol will complicate many things in our code base.

What is JavaScript specific about this protocol atm? It's just a uuid on the frame. It's open ended enough that it can be taken advantage of in other platforms as well!

I am with you on this. @mitsuhiko mentioned this as an issue. Maybe there are some other considerations we lack context for?

[lforst]

Honestly, writing this all down made me want to go with our original implementation again. It just makes so much more sense.

[mitsuhiko]

What is JavaScript specific about this protocol atm? It's just a uuid on the frame. It's open ended enough that it can be taken advantage of in other platforms as well!

We have evaluated this in the past and it's not that someone clearly decided against it. However it causes some extra complexity that we haven't been willing to consider yet. In particular debug_id for native files is not the only way to refer to them. There are also code_ids and others and it was not clear how much of that information wants to live on the frame. It also opened up uncomfortable questions about what happens when data disagrees between the two ways to refer to values.

I think we can evaluate debug_id on the frames, but it should probably be considered in the context of the already existing functionality.