Using a different thread's call stack for grouping

[mgooding]

For my Windows app I have a "watchdog" thread that checks whether the UI thread is remaining responsive. If it times out, the watchdog thread calls RaiseException to close the application and submit an error to Sentry.

I can see my UI thread's stack in Sentry and diagnose issues with this setup, but all crashes of this sort end up grouped together because they have the watchdog's thread stack. I'd like to use the UI thread's stack for grouping.

I looked at Stack Trace Rules and Fingerprint Rules and don't see an answer for working with other threads there. I could attach some kind of metadata before crashing and work up grouping rules myself, but I was wondering if there's a more straightforward answer I'm missing.

[supervacuus]

Hi @mgooding, this touches on a more significant topic with different use cases but for which Sentry currently doesn't provide a suitable solution:

• Sentry doesn't provide any grouping rules that would allow switching the identity thread from the crashing one to any other
• There are currently multiple properties in the event payload that could help with the problem of identifying the right thread for a crash, but
• the thread information is contained in the minidump and would have to be either duplicated or enriched in the client and then merged in the event processing and
• our event processing currently ignores/overwrites some of the properties (Adding minidump to event hides exception data. #268, Capturing an additional minidump as a error/non-crash event #823) because it was implemented with the idea of generating these properties solely from the minidump

The right place to modify these properties in the client SDK would be the on_crash callback in which you can adapt the passed-in event, which will then be sent with the crash minidump (this works on all platforms except crashpad on macOS).

Relevant properties in the event are:

• thread_id in the exception interface
• crashed in the threads interface

Be aware that the following policy (from the threads interface docs above) will be applied (during minidump event processing):

As per Sentry policy, the thread that crashed with an exception should not have a stack trace, but instead, the thread_id attribute should be set on the exception, and Sentry will connect the two.

This means you will end up with a JSON event payload containing an exception property that references a thread_id and a threads entry which will have that id and a property crashed: true, but it will be the exception that contains that stack trace and not the thread.

Ideally, for a use-case like yours, I would like to be able to set crashed: true (or provide a new property unresponsive: true) for the threads entry of your main thread and the event processing from then on would consider that thread to be the identity thread of that event (even though the minidump suggests otherwise). But alas, that would currently be ignored.

cc: @kahest, @Swatinem: am I missing something?