chore: remove SDK-side data truncation, defer to Relay

[dingsdax]

Summary

• Remove SDK-side truncation of event message text (8,192 char hard limit) and stacktrace argument variables (String.slice truncation)
• Relay already enforces the same limits with proper _meta annotations, so users now get visible truncation indicators in the Sentry UI instead of silent data loss

Message truncation removed (lib/sentry/client.ex)

Removed the @max_message_length (8,192) constant and String.slice call from sanitize_message/2. Relay already enforces the same limit on logentry.message and logentry.formatted, adding _meta truncation markers that the Sentry UI renders.

Stacktrace arg truncation removed (lib/sentry/event.ex)

Removed the String.slice call in stacktrace_args_to_vars/1, keeping only inspect(arg, inspect_opts). The inspect_opts (from :max_stacktrace_arg_length) still prevent the SDK from materializing huge strings, but the hard slice is gone so Relay can enforce its max_bytes = 2048 limit on frame vars with proper metadata.

fixes: ELIXIR-32
fixes: #937

[linear-code]

ELIXIR-32

[sentry]

Bug: Removing the hard truncation on stacktrace arguments can lead to excessively large output from inspect/2, as the new printable_limit and limit options do not fully constrain the size of complex data structures.
_{Severity: LOW}

Suggested Fix

To restore the safety guarantee, consider applying a final truncation to the output of the inspect call. For example, using inspect(arg, inspect_opts) |> String.slice(0, max_length) would ensure the resulting string for each argument does not exceed the configured max_stacktrace_arg_length, preventing pathologically large data from creating oversized payloads.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: lib/sentry/event.ex#L472

Potential issue: The removal of the hard `String.slice` truncation for stacktrace
arguments in `stacktrace_args_to_vars` introduces a risk of generating excessively large
strings. The `inspect/2` function is now used with `printable_limit` and `limit`
options, but these do not provide a complete safeguard. The `printable_limit` only
applies to strings and charlists, while `limit` only caps the number of elements in a
collection, not their individual sizes. A pathological data structure, such as a large
map where values are themselves large, complex terms, could bypass these limits and
produce an inspected string of millions of characters, potentially leading to high
memory consumption or issues with downstream services that have payload size limits.

Also affects:

• lib/sentry/client.ex:345~350

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[whatyouhide]

Yep this is technically correct—we'd be able to post huge inspected data structures to Sentry.

[dingsdax]

Relay enforces max_bytes=2048 + max_depth=5 on frame.vars via its TrimmingProcessor: anything over budget gets trimmed with ... and a _meta remark so the UI shows a truncation indicator.
The limits are defined in the stacktrace schema. So this should be fine.

[whatyouhide]

Right but isn't relay running on Sentry's servers? We'd still egress lots of data here no?

[dingsdax]

yes, but it's fine. this change aligns with what we do in other SDKs too, the main benefit is that the truncation shows up in the UI when done in Relay