refactor: Add nullability handling for data serialization

[philprime]

This PR is derived from #5572 in an effort to make the large amount of changes easier to review for #5577.

Should be merged after #5737

Fixes nullability handling and tests for the SentrySerialization and SentryEnvelope

#skip-changelog

[codecov]

❌ 9 Tests Failed:

Tests completed	Failed	Passed	Skipped
31863	9	31854	97

View the top 3 failed test(s) by shortest run time

SentryTests.SentryClientTest::testCaptureReplayEvent_preparingEventFails_shouldNotCaptureAndRecordLostEvent

Stack Traces | 0s run time

.../Tests/SentryTests/SentryClientTests.swift:2119 - XCTAssertEqual failed: ("0") is not equal to ("1")

SentryTests.SentryClientTest::testCaptureReplayEvent_preparingEventFails_shouldNotCaptureAndRecordLostEvent

Stack Traces | 0s run time

.../Tests/SentryTests/SentryClientTests.swift:2120 - XCTUnwrap failed: expected non-nil value of type "(category: SentryDataCategory, reason: SentryDiscardReason, quantity: UInt)"

SentryTests.SentryClientTest::testCaptureReplayEvent_preparingEventFails_shouldNotCaptureAndRecordLostEvent

Stack Traces | 0s run time

.../Tests/SentryTests/SentryClientTests.swift:2120 - XCTUnwrap failed: expected non-nil value of type "(category: SentryDataCategory, reason: SentryDiscardReason, quantity: UInt)"

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1214.10 ms	1229.34 ms	15.24 ms
Size	23.75 KiB	908.36 KiB	884.61 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
f8029e2	1245.16 ms	1261.32 ms	16.16 ms
2481950	1221.04 ms	1248.98 ms	27.94 ms
15c8cd5	1220.24 ms	1246.14 ms	25.90 ms
e64d3d4	1241.90 ms	1260.10 ms	18.20 ms
fac4ca3	1222.81 ms	1235.83 ms	13.02 ms
51f74d7	1236.31 ms	1247.43 ms	11.12 ms
5c5648e	1234.44 ms	1253.79 ms	19.35 ms
5ec90e0	1235.57 ms	1258.45 ms	22.88 ms
7148f97	1235.09 ms	1258.07 ms	22.98 ms
c63e0fe	1230.58 ms	1253.94 ms	23.35 ms

App size

Revision	Plain	With Sentry	Diff
f8029e2	23.75 KiB	893.72 KiB	869.97 KiB
2481950	23.74 KiB	872.74 KiB	849.00 KiB
15c8cd5	23.75 KiB	908.01 KiB	884.26 KiB
e64d3d4	23.75 KiB	855.37 KiB	831.62 KiB
fac4ca3	23.75 KiB	902.01 KiB	878.27 KiB
51f74d7	23.74 KiB	874.08 KiB	850.34 KiB
5c5648e	23.75 KiB	879.60 KiB	855.86 KiB
5ec90e0	23.74 KiB	872.67 KiB	848.92 KiB
7148f97	23.75 KiB	854.78 KiB	831.03 KiB
c63e0fe	23.74 KiB	874.08 KiB	850.33 KiB

Previous results on branch: philprime/strict-nullability-5

Startup times

Revision	Plain	With Sentry	Diff
cffd53d	1232.42 ms	1255.87 ms	23.46 ms

App size

Revision	Plain	With Sentry	Diff
cffd53d	23.75 KiB	908.36 KiB	884.61 KiB

[philprime]

Instead of skipping the recording data, it might make sense to abort the envelope initialization instead. WDYT?

[philipphofmann]

If a replay event without a recording is still somewhat useful, then I would say keep the envelope with only the replay event. If Relay or the backend discards such envelopes, then we could throw away the envelope here already.

[philprime]

I asked internally to find the best approach for this case.

[philipphofmann]

LGTM

[philipphofmann]

If a replay event without a recording is still somewhat useful, then I would say keep the envelope with only the replay event. If Relay or the backend discards such envelopes, then we could throw away the envelope here already.

[philprime]

Result from internal discussion:

When encoding of replay data fails, it should be propagated to the caller, to then drop the envelope and emit a client report.

[philipphofmann]

When encoding of replay data fails, it should be propagated to the caller, to then drop the envelope and emit a client report.

@philprime, we could also move the relay data serialization to its own PR. So basically, remove it from this PR and follow up. Then we can already merge this. Up to you if it's worth the effort.

[philprime]

@philipphofmann I looked into the propagation of the encoding result to report the dropped event. The PR is a work-in-progress, but the main problem I encountered is, that right now we if we return nil, the event is dropped as we want, but I can not use that as a trigger to record the lost event.

https://github.com/getsentry/sentry-cocoa/pull/5742/files#diff-47eb3eb3ea905acecc12679b7d5eac4688cb64f396c5e02f3213aefc5d0a639aR547-R550

If I leave the changes of the SentryClient.m like this, it would also record events which where filtered using beforeSend.

My idea would be changing the prepareEvent:withScope:alwaysAttachStacktrace to throw an error if encoding fails, but that would be quite a large change.

WDYT?

[github-actions]

🚨 Detected changes in high risk code 🚨

High-risk code can easily blow up and is hard to test. We had severe bugs in the past. Be extra careful when changing these files, and have an extra careful look at these:

• Sources/Sentry/SentrySerialization.m