getsentry / sentry

Developer-first error tracking and performance monitoring
https://sentry.io
Other
37.6k stars 4.04k forks source link

`stack.function` fail to match certain patterns #73661

Open lhunath opened 2 weeks ago

lhunath commented 2 weeks ago

Environment

SaaS (https://sentry.io/)

Steps to Reproduce

stack.package:**/UIKitCore stack.function:-[* +group
  1. Add a Stack Trace Rule such as the one above.
  2. Trigger an error event that includes a SwiftUI stack frame such as the one below.
  3. Take a look at the way the event is reported to be grouped.
    -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] 

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

getsantry[bot] commented 2 weeks ago

Auto-routing to @getsentry/product-owners-issues for triage ⏲️

scttcper commented 2 weeks ago

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/

lhunath commented 2 weeks ago

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.

scttcper commented 2 weeks ago

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

lhunath commented 2 weeks ago

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.

armenzg commented 2 weeks ago

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.

image image

In the first one (all frames) you will see that even UIApplicationMain is not being reached:

image

we don't even reach a few more frames below:

image
lhunath commented 2 weeks ago

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.

lhunath commented 2 weeks ago

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