Using inspect/2 with default options to print stacktrace info leads to limited printed output

[aghyad]

Environment

• Elixir version (elixir -v): any
• Erlang/OTP version (erl): any
• Sentry version (mix deps): any
• Operating system: any

Description

The current implementation of args_from_stacktrace/1 in Sentry.Event causes the output of inspects for stacktrace arguments to be limited and in a non-pretty format. This becomes obvious if your stacktrace is long and contains information you don't want omitted due to the default inspection limit.

:limit - limits the number of items that are printed for tuples, bitstrings, maps, lists and any other collection of items. 
It does not apply to strings nor charlists and defaults to 50. 
If you don't want to limit the number of items to a particular number, use :infinity.

Source: Inspect.Opts docs

Expected Behavior

To show the full stacktrace regardless of its size, and preferably in a beautiful format

Actual Behavior

Truncates the stacktrace by default due to inspect's default limitation, and for the same default settings of inspect, the stacktrace is not pretty-formatted

Steps to Reproduce

Try to log a long stack trace that surpasses inspect's limit stated in the docs referenced above, and you'll get the extra stackrace omitted

Suggested Fix

Explicitly, set the options of inspect/2 as:

limit: :infinity
pretty: true
structs: false
width: 0

[aghyad]

I just realized we have a PR for this opened earlier here: #331

[mitchellhenke]

@aghyad Thanks for opening this issue!

Going to tag #331 as it aims to solve this

Unfortunately, the expected behavior of showing the full stacktrace and arguments regardless of size isn't feasible, as Sentry has limits on the size of the payload it will receive. I expect that the suggested fix would be fine for most users, but switching from 50 to :infinity without any bounds is risky enough that I'm not comfortable defaulting all users to it. The first concern that comes to mind is a user not seeing an issue in Sentry because an event was rejected due to size that would normally have been trimmed and accepted.

I am very open to discussing how to better accommodate payloads larger than inspect emits by default. To help me understand and compare with other users, I'd like to know more about your use case. Are there specific types (tuples, lists, maps, bitstrings, etc.) that are an issue for you? What's the typical range on the length that doesn't fit into the default of 50?