Send crash reports if the app keeps crashing

[pepicrft]

Platform:

• iOS
• tvOS
• MacOS
• watchOS

Swift:

• Yes -> If yes, which version? 5.0.1
• No

sentry-cocoa installed with:

• CocoaPods
• Carthage
• Manually

Version of sentry-cocoa:
4.4.0

---

I have following issue:

I'm adding Sentry to an open source CLI written in Swift. I noticed that the reported crashes don't show up in the dashboard. I think the problem comes from the fact that the flush of those events happens asynchronously. Since the CLI runs very quickly, it terminates before the reported events are sent.

Steps to reproduce:

• Unzip the content in this file tuist-sentry.zip.
• Run tuist.

Actual result:
The app crashes but the crash doesn't show up in the dashboard.

Expected result:
The crash listed in the dashboard.

Proposal

Support passing a completion block to this method and make it public so that the consumer of the API can decide when to send the events and whether they want to wait for the completion.

[pepicrft]

If you think exposing that public API is a good idea I can implement it and open an PR. Let me know what you think about it.

[HazAT]

@pepibumur The feature, in general, makes sense and we want to have something like this. A PR is highly appreciated, we will soonish™ move this SDK towards being unified. In the unified SDK specs we have definded functions like flush / close on the transport which do exactly that.
https://docs.sentry.io/development/sdk-dev/unified-api/#client

[sjmadsen]

Is support for something like this still on the roadmap? I have a similar use case (in an iOS share extension), where the lifetime of the process could be very short and I'd like to flush any captured events to the server.

[philipphofmann]

Hi @sjmadsen, we have this feature on our list, but I can't give you an ETA. Whoever is interested in this feature can upvote here so we know it's important and maybe prioritize it higher.

[CraigSiemens]

I'd really like to see this feature. Currently sentry has no good handling for crashes that occur soon after launch so this would allow us to build our own handling until something like background requests (#271) are implemented and this wouldn't be needed.

[bruno-garcia]

That's fair. We need to at least implement a way to block startWithOptions until we process hard crashes.

or have flush work not only for in-flight events but also through the integration startup process, so we can block on flush until processing crashed events finishes.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[philipphofmann]

When the app crashed on a previous run, it makes sense to make the SDK init blocking to make sure the SDK sends the crash to Sentry. The downside is that this will cause slow down the app start. As this only happens after the app crashes, this tradeoff is acceptable.

[bruno-garcia]

We tried to address this in the .NET SDK with InitCacheFlushTimeout. It solves the problem there but with a side effect that it blocks on any pending envelope o disk, which is suboptimal. Now we have that learning, we can improve on this a bit. Perhaps adding a flag/file if the crash happened N seconds after SDK Init. So we only block in that case. Issue tracking there: getsentry/sentry-dotnet#1164

[philipphofmann]

Moved the details here getsentry/team-mobile#12

[bruno-garcia]

Tracking this more generally through: getsentry/team-mobile#12

[digitalmoksha]

I seem to be running into this problem as well. By accident I discovered a condition where my app crashes during startup, before the first window is shown. But a crash report was never received.

Restarting the app of course crashes again, and no report received in my dashboard.
If I then fix the problem, then the last crash does get sent and my other Sentry messages start getting received.

I'm just bummed that I have no idea how often this particular crash has been happening in the field.

[philipphofmann]

Thanks for your input, @digitalmoksha. Can you please press 👍 in the description above so we know how many people want this.

[digitalmoksha]

Done! 👍

[philipphofmann]

I think implementing flush (#1013) is a prerequisite.