You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first frame is un-ignored per the stack trace rule.
The recursing frames are ignored on account of recursion.
frame (un-ignored by stack trace rule (package:**/SwiftUI function:[-+]\[* +group))
function -[UIScrollView(SwiftUI) _swiftui_adjustsContentInsetWhenScrollDisabled]
frame (ignored due to recursion)
function -[UIScrollView(SwiftUI) _swiftui_adjustsContentInsetWhenScrollDisabled]
frame (ignored due to recursion)
function -[UIScrollView(SwiftUI) _swiftui_adjustsContentInsetWhenScrollDisabled]
Actual Result
Every frame that matches the rule, including the recusing frames, are un-ignored.
frame (un-ignored by stack trace rule (package:**/SwiftUI function:[-+]\[* +group))
function -[UIScrollView(SwiftUI) _swiftui_adjustsContentInsetWhenScrollDisabled]
frame (un-ignored by stack trace rule (package:**/SwiftUI function:[-+]\[* +group))
function -[UIScrollView(SwiftUI) _swiftui_adjustsContentInsetWhenScrollDisabled]
frame (un-ignored by stack trace rule (package:**/SwiftUI function:[-+]\[* +group))
function -[UIScrollView(SwiftUI) _swiftui_adjustsContentInsetWhenScrollDisabled]
It doesn't seem to be desirable to make the default behaviour be the one that is least useful, this makes the group sensitive to the # of recursions which is not the default Sentry stack grouping behaviour.
Furthermore, there is no simple way to restore the recursive check. One might be forced to explicitly write out sibling rules for each standard rule just to restore the default recursion behaviour. A recursion:yes/no matcher might be a useful addition if flipping the default behaviour by itself is inadequate.
Environment
SaaS (https://sentry.io/)
Steps to Reproduce
eg.
Expected Result
Actual Result
It doesn't seem to be desirable to make the default behaviour be the one that is least useful, this makes the group sensitive to the # of recursions which is not the default Sentry stack grouping behaviour.
Furthermore, there is no simple way to restore the recursive check. One might be forced to explicitly write out sibling rules for each standard rule just to restore the default recursion behaviour. A
recursion:yes/no
matcher might be a useful addition if flipping the default behaviour by itself is inadequate.Product Area
Issues
Link
https://hubstaff.sentry.io/issues/5565708392/events/bed216c2a2974d35b147bddd99587b01/
DSN
https://[email protected]/5277412
Version
8.25.0
The text was updated successfully, but these errors were encountered: