Open lhunath opened 2 weeks ago
Auto-routing to @getsentry/product-owners-issues for triage ⏲️
In the "By In-app Exception Stack-trace" it does look like a grouping rule is being applied. see un-ignored by stack trace rule your_rule
If you'd like more frames to be considered in the stacktrace i think you want them to be applied as "in-app" so you might try +app? https://docs.sentry.io/concepts/data-management/event-grouping/stack-trace-rules/
Thanks, but no, I do not what these frames to be considered in-app. They are not in-app frames. I only want them to be considered for the issue grouping, hence them having +group
and not +app
.
Note that the only frames included are the following:
frame (un-ignored by stack trace rule (package:**/UIKitCore function:UIApplicationMain +group))
function
UIApplicationMain
since it matches the rule
stack.package:**/UIKitCore stack.function:UIApplicationMain +group
But this issue is not related to this rule. This issue is related to the rule
stack.package:**/UIKitCore stack.function:-[* +group
Which ought to, but failed to, match against, eg.:
frame (non app frame)
function
-[UIApplication _run]
At least with this example we do have proof that the rule +group
works without adding +app
, it just doesn't work for the relevant rule.
I'd also try either increasing or removing family:native max-frames=10
which might be able to reach the frame you're interested in
That's not relevant, the frames are not native and we have proof that the rules are already reaching past this point seeing as the UIApplicationMain frame has successfully matched.
Hi @lhunath The event grouping information UI is not quite as clear as I wish it was. Let me know if the following info does not help.
There's one algorithm that only considers in-app frames and another with all.
In the first one (all frames) you will see that even UIApplicationMain
is not being reached:
we don't even reach a few more frames below:
Thanks!
I have indeed found the max-frames
action to be a bit confusing.
The documentation specifically uses it in an example like this:
family:native max-frames=3
Suggesting that akin to all other actions, they are constrained by the matchers that come on the same line before them.
However, I have discovered through experimentation that max-frames
is not constrained by matchers such as stack.package
. It would appear that it is also unconstrained by the family
matcher though perhaps I have misunderstood what native
means, since it is also not documented (my expectation was C/C++ frames, not higher-level languages).
Regardless, even if so, that doesn't explain why the stack.package
matcher had not constrained the max-frames
.
That probably should be either clearly documented, the example fixed, OR (better yet) the behaviour fixed such that the actual behaviour matches the documentation.
Regardless, that is a separate issue to this one.
I have modified the pattern in an attempt to find a working alternative and the following pattern does succeed at matching the expected frame:
package:**/UIKitCore function:[-+]\[* +group
Environment
SaaS (https://sentry.io/)
Steps to Reproduce
Expected Result
The frame is taken into account in the grouping logic on account of overriding the default grouping logic for the frame with the rule specified above. Alternatively, if the pattern is invalid, a validation error when saving the pattern.
Actual Result
The frame is ignored on account of default grouping logic applying and not getting overridden by the rule above.
Product Area
Issues
Link
https://hubstaff.sentry.io/issues/5458344733/events/ecef19ff26e8443c9622a2a20b0e479d/
DSN
https://d5eb5898c01249b7a9396e7fa5deea1b@o378389.ingest.sentry.io/5277412
Version
No response