Error tracking source code context in stack frames#87
Conversation
posthog-elixir Compliance ReportDate: 2026-03-19 12:20:20 UTC ✅ All Tests Passed!29/29 tests passed Capture Tests✅ 29/29 tests passed View Details
|
rafaeelaudibert
left a comment
There was a problem hiding this comment.
I'm not familiar with maps but this seems to be working well! Make sure we've done extensive testing before merging this :)
@martosaur I know you're using Error Tracking in production, wondering if you're missing what's being implemented here or does this feel like extra work for no reason?
| defp value(%{meta: %{crash_reason: {reason, _stacktrace}}}) when is_exception(reason), | ||
| do: %{value: Exception.message(reason)} | ||
|
|
||
| defp value(%{meta: %{crash_reason: {{:nocatch, throw}, stacktrace}}}), | ||
| do: %{value: Exception.format_banner(:throw, throw, stacktrace)} | ||
| defp value(%{meta: %{crash_reason: {{:nocatch, throw}, _stacktrace}}}), | ||
| do: %{value: inspect(throw)} | ||
|
|
||
| defp value(%{meta: %{crash_reason: {reason, stacktrace}}}), | ||
| do: %{value: Exception.format_banner(:exit, reason, stacktrace)} | ||
| defp value(%{meta: %{crash_reason: {reason, _stacktrace}}}), | ||
| do: %{value: Exception.format_exit(reason)} |
There was a problem hiding this comment.
This will change the message we have in Prod which will create new errors, right? Or am I misunderstanding this @cat-ph ?
There was a problem hiding this comment.
we don't use the values for the fingerprint linking to issues, so it keeps them and doesn't create new ones! (just verified this too below, 1. before, 2. after; thanks for checking! 😆)
I think we could consider actually maybe separating the type like ** (exit) as the type and the rest as the value, but that would create new issues, and is right now pretty standard elixir format (I think) so that's why I didn't change that
lib/posthog/handler.ex
Outdated
| if config.enable_source_code_context do | ||
| case PostHog.Sources.get_source_map_for_file(filename) do | ||
| nil -> | ||
| frame | ||
|
|
||
| source_map_for_file -> | ||
| {pre_context, context_line, post_context} = | ||
| PostHog.Sources.get_source_context( | ||
| source_map_for_file, | ||
| lineno, | ||
| config.context_lines | ||
| ) | ||
|
|
||
| frame | ||
| |> Map.put(:context_line, context_line) | ||
| |> Map.put(:pre_context, pre_context) | ||
| |> Map.put(:post_context, post_context) | ||
| end | ||
| else | ||
| frame | ||
| end |
There was a problem hiding this comment.
Can probably do this with a with block to make it looks slightly cleaner?
lib/posthog/sources.ex
Outdated
| @@ -0,0 +1,198 @@ | |||
| defmodule PostHog.Sources do | |||
There was a problem hiding this comment.
Sources is a very generic name. How about PostHog.ErrorTracking.Sources?
There was a problem hiding this comment.
good point, I was thinking we might use them later for other stuff, but not sure what exactly for so YAGNI, updated!
lib/posthog/sources.ex
Outdated
| # Part of this approach is inspired by getsentry/sentry-elixir by Software, Inc. dba Sentry | ||
| # Licensed under the MIT License | ||
| # - sentry-elixir/lib/sentry/sources.ex | ||
| # - sentry-elixir/lib/mix/tasks/sentry.package_source_code.ex | ||
|
|
||
| # 💖 open source (under MIT License) |
There was a problem hiding this comment.
I assume this should be a trailer comment at the top of the file instead?
There was a problem hiding this comment.
Also, confirm the base LICENSE files mention this or else we're not compliant.
There was a problem hiding this comment.
updated, ty! trailer comment in both + LICENSE mention
code source is a nice QoL addition for sure. I'm just not very familiar with how it works exactly in any other lib, so can't really tell good from bad without doing some research |
…ate LICENSE - Move PostHog.Sources → PostHog.ErrorTracking.Sources - Add Sentry-elixir attribution headers in sources.ex and mix task - Update LICENSE to note inspired portions and credit Sentry - Refactor handler.maybe_add_source_context to use with block - Fix nested module alias (credo strict) - Move test file to match new module path
|
thanks @martosaur and @rafaeelaudibert - I think there are some potential approaches, this seems like probably the most straightforward, also has its cons (since technically source code will live with the release files, and hot code upgrades could get messy / cause drift). Others we were thinking could be 1. using something like We could also in the future support uploading these custom maps with a predefined format & version and resolving them on our side instead |
Adds source code context to error tracking stack frames, allowing us to display lines of code around the error location.
Changes