From 4b246b7f042059eab53ae27f7bf667b7e57647b3 Mon Sep 17 00:00:00 2001 From: Ivan Dlugos Date: Wed, 15 Feb 2023 12:54:17 +0100 Subject: [PATCH 1/5] rfc(feature): Source context via links --- README.md | 1 + text/0074-source-context-via-links.md | 35 +++++++++++++++++++++++++++ 2 files changed, 36 insertions(+) create mode 100644 text/0074-source-context-via-links.md diff --git a/README.md b/README.md index 301a7ca5..cb74f359 100644 --- a/README.md +++ b/README.md @@ -35,3 +35,4 @@ This repository contains RFCs and DACIs. Lost? - [0070-document-sensitive-data-collected](text/0070-document-sensitive-data-collected.md): Document sensitive data collected - [0071-continue-trace-over-process-boundaries](text/0071-continue-trace-over-process-boundaries.md): Continue trace over process boundaries - [0072-kafka-schema-registry](text/0072-kafka-schema-registry.md): Kafka Schema Registry +- [0074-source-context-via-links](text/0074-source-context-via-links.md): Source context via links diff --git a/text/0074-source-context-via-links.md b/text/0074-source-context-via-links.md new file mode 100644 index 00000000..e8ee00d2 --- /dev/null +++ b/text/0074-source-context-via-links.md @@ -0,0 +1,35 @@ +- Start Date: 2023-02-15 +- RFC Type: feature +- RFC PR: https://github.com/getsentry/rfcs/pull/74 +- RFC Status: draft + +# Summary + +One paragraph explanation of the feature or document purpose. + +# Motivation + +Why are we doing this? What use cases does it support? What is the expected outcome? + +# Background + +The reason this decision or document is required. This section might not always exist. + +# Supporting Data + +[Metrics to help support your decision (if applicable).] + +# Options Considered + +If an RFC does not know yet what the options are, it can propose multiple options. The +preferred model is to propose one option and to provide alternatives. + +# Drawbacks + +Why should we not do this? What are the drawbacks of this RFC or a particular option if +multiple options are presented. + +# Unresolved questions + +- What parts of the design do you expect to resolve through this RFC? +- What issues are out of scope for this RFC but are known? From e44d4a2c05c14428c67e9d293f19f84ed54438ca Mon Sep 17 00:00:00 2001 From: Ivan Dlugos Date: Wed, 15 Feb 2023 14:05:49 +0100 Subject: [PATCH 2/5] update the RFC --- text/0074-source-context-via-links.md | 63 +++++++++++++++++++++------ 1 file changed, 49 insertions(+), 14 deletions(-) diff --git a/text/0074-source-context-via-links.md b/text/0074-source-context-via-links.md index e8ee00d2..2a175519 100644 --- a/text/0074-source-context-via-links.md +++ b/text/0074-source-context-via-links.md @@ -1,35 +1,70 @@ - Start Date: 2023-02-15 - RFC Type: feature -- RFC PR: https://github.com/getsentry/rfcs/pull/74 +- RFC PR: - RFC Status: draft # Summary -One paragraph explanation of the feature or document purpose. +In situations where a source code link and a line number is available for a frame, present the link in the UI and show +the source code surrounding the line. # Motivation -Why are we doing this? What use cases does it support? What is the expected outcome? +The source context is currently composed of three [`Frame` attributes](https://develop.sentry.dev/sdk/event-payloads/stacktrace/#frame-attributes): -# Background +- `context_line` - Source code in filename at `lineno`. +- `pre_context` - A list of source code lines before `context_line` (in order) – usually [`lineno - 5:lineno`]. +- `post_context` - A list of source code lines after `context_line` (in order) – usually [`lineno + 1:lineno + 5`]. -The reason this decision or document is required. This section might not always exist. +Showing a source code context and a link to it (e.g. to GitHub) currently works only if the source code itself is +available during symbolication, thus the attributes are filled in at that time, or if they were already sent with the event by the SDK. -# Supporting Data +There are, however, situations where we do have a URL where the source code resides, but not the contents (without downloading it), for example: -[Metrics to help support your decision (if applicable).] +- Portable-PDB source-link (.NET, see [this `symbolic` issue](https://github.com/getsentry/symbolic/issues/735)) +- via a repository integration in combination with associated commit + +In these cases, the actual source code is not necessary to do symbolication (as opposed to source maps and other types of obfuscated source containers) but it is useful for end-user +when evaluating the issue in the UI. + +## Related GH feature requests + +- [Extend stack-trace linking UI](https://github.com/getsentry/sentry/issues/35608) +- [Support stack trace linking when stack frames do not contain line context.](https://github.com/getsentry/sentry/issues/44015) # Options Considered -If an RFC does not know yet what the options are, it can propose multiple options. The -preferred model is to propose one option and to provide alternatives. +## A | Download the source code during symbolication + +One option is to download the source code from its link at the time the event is symbolicated, filling the context-related +`Frame` attributes for each stacktrace frame, while the event is being processed. + +### Pros + +- Reuses existing fields (changes only needed in the `Symbolicator`). +- Sources surrounding the frame line are then stored in the database, enabling [search-by-code](https://github.com/getsentry/sentry/issues/3755). +- May be possible to do server-side authentication (based on project/org configuration) - this would complicate the solution & caching though, as opposed to only supporting publicly available sources. + +### 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. + +## B | Add a source-link to the `Frame` and let the UI handle it + +Another option is to extend `Frame` attributes with a new field, e.g. `source_link` and let UI download the source code +as needed or just display the link. + +### 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. -# Drawbacks +### Cons -Why should we not do this? What are the drawbacks of this RFC or a particular option if -multiple options are presented. +- Sources not available in the database -> can't [search-by-code](https://github.com/getsentry/sentry/issues/3755). +- Accessing private sources may be problematic. We could still show the source link, though. # Unresolved questions -- What parts of the design do you expect to resolve through this RFC? -- What issues are out of scope for this RFC but are known? +- Neither approach is a clear winner, any suggestions? From 693514173c223c415a64b3a22f49b8e6722d9335 Mon Sep 17 00:00:00 2001 From: Ivan Dlugos <6349682+vaind@users.noreply.github.com> Date: Thu, 16 Feb 2023 16:35:48 +0100 Subject: [PATCH 3/5] Update text/0074-source-context-via-links.md --- text/0074-source-context-via-links.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/text/0074-source-context-via-links.md b/text/0074-source-context-via-links.md index 2a175519..6beac6f1 100644 --- a/text/0074-source-context-via-links.md +++ b/text/0074-source-context-via-links.md @@ -22,6 +22,8 @@ available during symbolication, thus the attributes are filled in at that time, There are, however, situations where we do have a URL where the source code resides, but not the contents (without downloading it), for example: - Portable-PDB source-link (.NET, see [this `symbolic` issue](https://github.com/getsentry/symbolic/issues/735)) +- Debuginfod servers (we don’t support these yet) +- SourceMaps (either embedded sourcesContent or using individual source files) - via a repository integration in combination with associated commit In these cases, the actual source code is not necessary to do symbolication (as opposed to source maps and other types of obfuscated source containers) but it is useful for end-user From 589c23b6e77c344c7994bdccd24b6f6a67229655 Mon Sep 17 00:00:00 2001 From: Ivan Dlugos Date: Sat, 18 Mar 2023 13:28:30 +0100 Subject: [PATCH 4/5] update based on recent development --- text/0074-source-context-via-links.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/text/0074-source-context-via-links.md b/text/0074-source-context-via-links.md index 6beac6f1..92672736 100644 --- a/text/0074-source-context-via-links.md +++ b/text/0074-source-context-via-links.md @@ -19,15 +19,15 @@ The source context is currently composed of three [`Frame` attributes](https://d Showing a source code context and a link to it (e.g. to GitHub) currently works only if the source code itself is available during symbolication, thus the attributes are filled in at that time, or if they were already sent with the event by the SDK. -There are, however, situations where we do have a URL where the source code resides, but not the contents (without downloading it), for example: +There are, however, situations where we do have a URL representing the source code contents, but not the contents itself (without downloading it), for example: - Portable-PDB source-link (.NET, see [this `symbolic` issue](https://github.com/getsentry/symbolic/issues/735)) - Debuginfod servers (we don’t support these yet) - SourceMaps (either embedded sourcesContent or using individual source files) - via a repository integration in combination with associated commit -In these cases, the actual source code is not necessary to do symbolication (as opposed to source maps and other types of obfuscated source containers) but it is useful for end-user -when evaluating the issue in the UI. +In these cases, the actual source code is not necessary to do symbolication (as opposed to source maps and other types +of obfuscated source containers) but it is useful for end-user when evaluating the issue in the UI. ## Related GH feature requests @@ -67,6 +67,9 @@ as needed or just display the link. - Sources not available in the database -> can't [search-by-code](https://github.com/getsentry/sentry/issues/3755). - Accessing private sources may be problematic. We could still show the source link, though. -# Unresolved questions +# Selected Option - Combined approach -- Neither approach is a clear winner, any suggestions? +Because neither option is a clear winner, we went for a combined approach, i.e. + +- Add a `source_link` field to the frame. +- Resolve source context from remote URLs, but only for in-app frames. From 286dec82eee561bc74aa9045a9d514faf1d9b102 Mon Sep 17 00:00:00 2001 From: Ivan Dlugos <6349682+vaind@users.noreply.github.com> Date: Thu, 30 Mar 2023 14:22:11 +0200 Subject: [PATCH 5/5] Update text/0074-source-context-via-links.md Co-authored-by: Arpad Borsos --- text/0074-source-context-via-links.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0074-source-context-via-links.md b/text/0074-source-context-via-links.md index 92672736..5be75a76 100644 --- a/text/0074-source-context-via-links.md +++ b/text/0074-source-context-via-links.md @@ -22,7 +22,7 @@ available during symbolication, thus the attributes are filled in at that time, There are, however, situations where we do have a URL representing the source code contents, but not the contents itself (without downloading it), for example: - Portable-PDB source-link (.NET, see [this `symbolic` issue](https://github.com/getsentry/symbolic/issues/735)) -- Debuginfod servers (we don’t support these yet) +- [Debuginfod servers](https://www.mankier.com/8/debuginfod#Webapi-/buildid/BUILDID/source/SOURCE/FILE) (we don’t support these yet) - SourceMaps (either embedded sourcesContent or using individual source files) - via a repository integration in combination with associated commit