rfc(feature): Source context via links #74
Conversation
b613e3d to
b30618a
Compare
|
My vote is for option A. It seems like with option B we'd need to think about anywhere that data might need to be rendered - which might not just be the UI. You called out search, but there could be others. Perhaps with integrations or alerts (if not now, then in the future). |
|
A third option (not my first choice though) would be to have Sentry CLI download the files from the links and use them to create a source bundle, then upload the source bundle through the existing mechanism. That would address .NET SourceLink, but I'm not sure it would cover the other cases mentioned. |
|
|
||
| ### Cons | ||
|
|
||
| - Downloads all frame sources even though the event/frame may never be viewed by a user. |
There was a problem hiding this comment.
Slightly related:
We should make "we want source context" configurable / an input option in symbolicator.
For example the profiling product goes through symbolicator, but does not use source context at all (they throw it away in the profiling processor AFAIK). We could potentially make profiles cheaper to symbolicate by just not doing source context resolution at all. CC @indragiek
It may also be worth considering making the lines of context configurable, as it is hardcoded to 5 right now.
| ### Cons | ||
|
|
||
| - Downloads all frame sources even though the event/frame may never be viewed by a user. | ||
| - Adds potentially tens of requests for each symbolicated event that has a source link - as many as there are in the stack trace. |
There was a problem hiding this comment.
Agreed, it adds a ton of requests, and processing to stack frames that customers are very unlikely to ever look at (for example background threads). Though good caching should hopefully take care of most of this.
I’m not sure we have metrics for any of this right now? How many stack traces users are actually looking at?
| ### Pros | ||
|
|
||
| - No overhead on the server for loading sources in situations where the event/frame wouldn't be shown. | ||
| - Requests to fetch the source code, if any, are made by the user browser, thus avoiding potential quota limits. |
There was a problem hiding this comment.
Well, while we as a single large consumer would not run into quotas, the source server itself would get a ton more requests by individual users that are not being cached.
|
|
||
| # Unresolved questions | ||
|
|
||
| - Neither approach is a clear winner, any suggestions? |
There was a problem hiding this comment.
I believe from an implementation POV, we can even do a hybrid approach:
- Always attach a source link to stack frames.
- Only download/apply source context for the top N frames of the crashing thread.
With that, we can focus the ahead-of-time work to the context the end user is most likely to actually look at, and search for; while keeping options open for the future.
I believe this is big enough to involve more people from the product side of things, to answer the following questions:
- Which parts of the product need source context?
- How much (lines of) source context?
- How does this tie into search-by-code?
- Do we need all the source context at once, or is it okay to lazily load some of it at a later time (favoring a hybrid approach)
Yes, that occurred to me too, originally, but I've abandoned that quickly because it doesn't translate to debug info coming from dependencies (e.g. snuget) that will only be loaded on the server during symbolication |
da3db10 to
589c23b
Compare
|
Who can review & merge this? As is, it just describes what is in production already & some future ideas |
Co-authored-by: Arpad Borsos <swatinem@swatinem.de>
Evaluates options to support source context via source links (URLs).
Rendered RFC