[Release Health] Unable to conditionally update sessions for certain kinds of dumps

[souredoutlook]

Problem Statement

Related to: #722 (comment)

While it is possible to filter out events where DumpWithoutCrashing is the cause, these events still count against the crash free rate for sessions.

Currently it is not possible to conditionally update sessions where a crash is percieved to have happened (even though it may or may not be percieved by the end user of the app).

Solution Brainstorm

In JS SDKs typically you can prevent session updates or manually revert updates to a session where the last event was dropped in an event processor.

Given how Main Process sessions are stored to disk this is not as simple in Electron.

[AbhiPrasad]

The tricky thing is that I'm not sure we can identify a minidump as a DumpWithoutCrashing without parsing it server-side 😢.

Maybe @timfish has ideas, but I'll also reach out to native team folks.

[timfish]

What typically causes DumpWithoutCrashing minidumps?

I assumed these were caused by manually triggering a minidump with the debugger attached?

[AbhiPrasad]

I was linked this thread, but it lacks details: https://groups.google.com/a/chromium.org/g/chromium-dev/c/r8GmY_Ug2Mo?pli=1

@souredoutlook do you have other links to resources that explain how DumpWithoutCrashing is being called?

[timfish]

It looks like it might be a means for Chromium to collect minidumps for specific things that they're trying to debug and get more information for and these shouldn't make it into stable builds 🤔

Do we have symbolicated stack traces for where in Chromium these are getting triggered from?

Perhaps Electron can exclude these from their build or one hasn't been correctly flagged in the chromium source and has made it into stable. It's probably worth opening an issue upstream with Electron with a full stack trace and posing the question?