Remove unnecessary SDK-side data truncation and rely on Relay for handling max length limits.

[dingsdax]

Review implementation for any truncation of event data (e.g., error titles, stack frames, local variables). Remove truncation where possible so that Relay handles length limits and marks truncated content clearly for users.

• Keep only essential truncation needed to prevent issues e.g. such as infinite or near-infinite recursion if applicable
• Verify Relay’s configured limits before making changes, and test to ensure ingestion works as expected (exception type field example)

In scope: any code paths where data is shortened in a way that hides useful information for debugging

Out of scope: Limits explicitly decided in the past (e.g., 1000 spans per transaction, max breadcrumbs, request body truncation).

See also:
https://develop.sentry.dev/sdk/data-model/envelopes/#size-limits

[linear]

RUST-100 Remove unnecessary SDK-side data truncation and rely on Relay for handling max length limits. (copy)

[lcian]

This is the only place where we truncate.

sentry-rust/sentry-backtrace/src/trim.rs

Lines 29 to 56 in 045c2e2

	const WELL_KNOWN_BORDER_FRAMES: &[&str] = &[
	"std::panicking::begin_panic",
	"core::panicking::panic",
	// well-known library frames
	"anyhow::",
	"<sentry_log::Logger as log::Log>::log",
	"tracing_core::",
	];
	/// A helper function to trim a stacktrace.
	pub fn trim_stacktrace<F>(stacktrace: &mut Stacktrace, f: F)
	where
	F: Fn(&Frame, &Stacktrace) -> bool,
	{
	let known_cutoff = stacktrace
	.frames
	.iter()
	.rev()
	.position(|frame| match frame.function {
	Some(ref func) => is_well_known_border_frame(func) || f(frame, stacktrace),
	None => false,
	});
	if let Some(cutoff) = known_cutoff {
	let trunc = stacktrace.frames.len() - cutoff - 1;
	stacktrace.frames.truncate(trunc);
	}
	}

To be investigated whether this can change grouping and if it could make things worse.

[lcian]

If the binary has debug symbols, we use the logic in https://github.com/getsentry/sentry-rust/blob/master/sentry-backtrace/src/process.rs to divide frames into in_app and not in_app.
As a consequence, the grouping logic can group by "In-app Exception Stacktrace".
This means that changing the trimming logic won't have any effect, because what we're trimming is always not in-app anyways.

[lcian]

If the binary doesn't have debug symbols, we cannot mark anything as in_app or not.
However, on the server side we have similar rules to mark system frames. The consequence is that the in_app frames are similar to what you would get when debug symbols are available.
Therefore, grouping doesn't change in this case as well.

[lcian]

Note that above I tested with panics, before changing this I would need to test more cases and integrations.

Overall though, these frames that we trim are always completely useless for debugging purposes, and should always be not in_app, meaning that they would not be shown to users by default even if we would send them.

For these reason, I would prefer to keep the stack trace trimming logic as is.
To recap, we would have to do more work to investigate all cases, for very little benefit, and with a risk of creating new groups for some users.