Capture "Startup Crashes"

[bruno-garcia]

Problem

Most SDKs submit crash events in the background to not slow down the app start. When a crash happens immediately after SDK init it will never be sent to Sentry. Such a crash is called a start-up crash.

Solution

When the app crashes shortly (x seconds) after SDK is initialized, the SDK writes a marker file to the disk indicating the app crashes shortly after the SDK init.
The SDK init function doesn't return until the start-up crash is sent to Sentry or until a configurable timeout is reached.
If the timeout is reached the init function should return and the crash submission should continue in the background.

• Develop docs: feat: Start-up crashes develop#730
• Put this into the features list https://docs.sentry.io/platforms/apple/guides/ios/

More details:

• Startup Crash: Only block Init to flush events if the app crashed on the last run sentry-dotnet#1164
• Send crash reports if the app keeps crashing sentry-cocoa#316
• Report Startup Crashes sentry-java#2277

https://sentry.zendesk.com/agent/tickets/62388

[philipphofmann]

Only flushing out the crash event makes things a bit complicated because:

• we need to guarantee that the SDK sends the session init only once and only before other session updates
• we can't use flush, which already exists in most SDKs. The SDK needs extra logic for this.

Most of the time, there shouldn't be too many envelopes queued for sending. Simply calling flush for all envelopes should be enough for 80% or more of the start-up crashes. I suggest we keep the logic simple and accept the tradeoff that maybe in some cases, the SDK will flush out other envelopes first before sending the start-up crash. We can iterate on this feature later.

Do you agree with this approach @bruno-garcia, @mattjohnsonpint, @marandaneto, @adinauer, @brustolin, @bitsandfoxes? If yes, comment with 👍. Otherwise, please add your concerns.

[philipphofmann]

We (@brustolin, @marandaneto, @romtsn, and @philipphofmann) decided to use 5 seconds for the blocking flushing call, and that crashes happening 2 seconds after the SDK init are start-up crashes.

[kahest]

Closing this mobile meta issue, Unity/.NET tracks remaining work separately