Finish and capture transaction/span bound to the Scope in case of a fatal crash

[kahest]

Description

For now the transaction gets lost in case of a fatal crash. We should finish it with an appropriate status before capturing the exception, if possible.

See getsentry/team-mobile#62

[philipphofmann]

At the moment, I can think of two ways to achieve this.

Option A

In case of a fatal crash, we could call into ObjC to finish the ongoing transactions after SentryCrash has written the crash report to disk. We already use this approach for screenshots and view hierarchy, but it wouldn't work for all types of crashes. This would be the best effort approach.

sentry-cocoa/Sources/SentryCrash/Recording/SentryCrashC.c

Lines 111 to 117 in 58f558d

	// Report is saved to disk, now we try to take screenshots
	// and view hierarchies.
	// Depending on the state of the crash this may not work
	// because we gonna call into non async-signal safe code
	// but since the app is already in a crash state we don't
	// mind if this approach crashes.
	if (g_saveScreenShot || g_saveViewHierarchy) {

Option B

To make this work for all types of crashes, we would need to sync the transaction from ObjC to C memory and store it alongside a crash report. This approach is similar to syncing the scope data to SentryCrash.

sentry-cocoa/Sources/Sentry/include/SentryCrashScopeObserver.h

Lines 6 to 19 in 58f558d

	/**
	* This class performs a fine-grained sync of the Scope to C memory, as when SentryCrash writes a
	* crash report, we can't call Objective-C methods; see SentryCrash.onCrash. For every change to the
	* Scope, this class serializes only the changed property to JSON and stores it in C memory. When a
	* crash happens, the SentryCrashReport picks up the JSON of all properties and adds it to the crash
	* report.
	*
	* Previously, the SDK used SentryCrash.setUserInfo, which required the serialization of the whole
	* Scope on every modification of it. When having much data in the Scope this slowed down the caller
	* of the scope change. Therefore, we had to move the Scope sync to a background thread. This has
	* the downside of the scope not being 100% up to date when a crash happens and, of course, lots of
	* CPU overhead.
	*/
	@interface SentryCrashScopeObserver : NSObject <SentryScopeObserver>

This approach would add some overhead, as every change to a span or transaction would trigger a sync to c memory. To keep this performant a fine-grained sync is a must, which only syncs the current change of a span or transaction to SentryCrash, instead of the whole transaction.

[brustolin]

I believe this is an edge case that don't worth doing option B.

[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 🥀