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]

Codecov Report

❌ Patch coverage is 93.75000% with 4 lines in your changes missing coverage. Please review.
⚠️ Please upload report for BASE (main@9080e6c). Learn more about missing BASE report.
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
Sources/Sentry/SentryEnvelope.m	80.000%	4 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main     #5742   +/-   ##
========================================
  Coverage        ?   86.750%           
========================================
  Files           ?       424           
  Lines           ?     36704           
  Branches        ?     17362           
========================================
  Hits            ?     31841           
  Misses          ?      4818           
  Partials        ?        45           

Files with missing lines	Coverage Δ
Sources/Sentry/SentryClient.m	98.934% <100.000%> (ø)
Sources/Sentry/SentrySerialization.m	98.905% <100.000%> (ø)
Sources/Sentry/SentryEnvelope.m	88.687% <80.000%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9080e6c...3c6cb55. Read the comment docs.

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1219.24 ms	1255.54 ms	36.30 ms
Size	23.75 KiB	926.89 KiB	903.14 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
e8da57d	1203.77 ms	1234.85 ms	31.08 ms
f5d202b	1237.90 ms	1259.49 ms	21.59 ms
64c2b2b	1233.96 ms	1260.20 ms	26.24 ms
9e0030e	1222.78 ms	1242.23 ms	19.45 ms
2bddb03	1214.11 ms	1246.78 ms	32.67 ms
0b5fd21	1237.52 ms	1251.36 ms	13.84 ms
be6a4ee	1226.33 ms	1249.77 ms	23.44 ms
2609f7a	1218.17 ms	1241.34 ms	23.17 ms
cda95fc	1231.42 ms	1247.18 ms	15.77 ms
b045d0a	1227.48 ms	1252.22 ms	24.75 ms

App size

Revision	Plain	With Sentry	Diff
e8da57d	23.75 KiB	919.69 KiB	895.94 KiB
f5d202b	23.75 KiB	904.53 KiB	880.78 KiB
64c2b2b	23.75 KiB	908.55 KiB	884.80 KiB
9e0030e	23.75 KiB	893.72 KiB	869.97 KiB
2bddb03	23.75 KiB	891.01 KiB	867.26 KiB
0b5fd21	23.75 KiB	912.78 KiB	889.03 KiB
be6a4ee	23.75 KiB	913.14 KiB	889.39 KiB
2609f7a	23.75 KiB	867.04 KiB	843.29 KiB
cda95fc	23.75 KiB	912.77 KiB	889.02 KiB
b045d0a	23.75 KiB	880.21 KiB	856.46 KiB

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

Startup times

Revision	Plain	With Sentry	Diff
ecde351	1214.10 ms	1229.34 ms	15.24 ms
c8a4790	1231.27 ms	1250.06 ms	18.79 ms
cffd53d	1232.42 ms	1255.87 ms	23.46 ms

App size

Revision	Plain	With Sentry	Diff
ecde351	23.75 KiB	908.36 KiB	884.61 KiB
c8a4790	23.75 KiB	920.33 KiB	896.58 KiB
cffd53d	23.75 KiB	908.36 KiB	884.61 KiB

[philipphofmann]

LGTM

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

[philprime]

cursor review

[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