ref(trimming): Keep frames from both ends of the trace

[Dav1dde]

Currently we trim frames from only one end of the stacktrace, this works decently well except for recursion errors where you would also be interested in what triggered the recursion initially.

Adjust the trimming to keep some frames from the beginning of the trace, the majority is still taken from the end.

[olksdr]

Changes LGTM!

But I'm mostly curious if this change makes sense product-wise.
Let's involved the requester of this change add more info on why exactly this needed and if this doesn't break the current product experience.

[realkosty]

But I'm mostly curious if this change makes sense product-wise. Let's involved the requester of this change add more info on why exactly this needed and if this doesn't break the current product experience.

@olksdr you're right, we should involve product as this has potential to impact grouping of existing issues.
@rachrwang @lobsterkatie
Here is the context and customer request: https://sentry.slack.com/archives/C019637C760/p1723069888501309
First step might be get a sense of what %-age of events has between 200 and 250 frames -> the ones potentially affected.
On the other hand, newly added "bottom" 50 frames that were previously trimmed starting to match existing stack trace/fingerprint/ownership rules probably more of a feature than bug.

[lobsterkatie]

IDK that I have any expertise here, but naively I guess my question would be, what would this look like in the product? (I actually don't know what it looks like when we trim only from one end, either.) Will it be clear to the user what's happened and why?

[realkosty]

Currently product shows no indication that frames were trimmed. The only way to know that is guessing that whatever ends up as the first frame doesn't look like thread base or main entry point.
This change without product support (some kind of "..." in UI) might make in in some sense more confusing as it may be hard to understand where the splice point is

[SurenNihalani]

Can we get traction on this? This is making life hard while debugging recursion bugs

[jan-auer]

G2G. I would recommend to show in the user interface that frames were trimmed.

[SurenNihalani]

Thanks for merging this. when do we expect this to deployed onto sentry?

Stretch ask: It'd be nice to just deduplicate duplicate frames instead of trimming

[realkosty]

@SurenNihalani Most likely deployed already.

Related: getsentry/sentry#61034

[Dav1dde]

Thanks for merging this. when do we expect this to deployed onto sentry?

Should be out already!

Stretch ask: It'd be nice to just deduplicate duplicate frames instead of trimming

No, that's definitely a good idea, opened an issue #3956, feel free to leave a comment if you think I missed something in the description!