fix: Add manual file IO tracking for Swift.Data

[philprime]

Open Sub Tasks:

• Decide if refactoring SentryNSDataTracker to SentryFileIOTracker
• Decide if iOS/macOS availability check is necessary
• Remove changes in GitHub Actions before merging, as the changes are in chore: Bump OS versions for unit tests #4542 instead
• Fix unit tests in SentryFileIOTrackingIntegrationTests.swift

Out-of-scope for this PR:

• Add checks to detect cascading spans created by swizzled methods calling other swizzled methods

Closes #4546

[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/SentryNSFileManagerSwizzling.m

[philprime]

We could consider to refactor the class SentryNSDataTracker to a broader name like SentryFileIOTracker as we are adding methods not directly related to NSData

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1207.49 ms	1231.92 ms	24.43 ms
Size	22.31 KiB	776.76 KiB	754.44 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
279841c	1250.80 ms	1263.08 ms	12.29 ms
a176fc4	1239.78 ms	1258.98 ms	19.20 ms
d26797f	1226.98 ms	1240.14 ms	13.16 ms
e19cca3	1215.39 ms	1235.21 ms	19.83 ms
becc941	1221.90 ms	1240.37 ms	18.47 ms
279841c	1231.41 ms	1245.65 ms	14.24 ms
c319795	1220.06 ms	1248.50 ms	28.44 ms
94d8eb3	1234.02 ms	1249.63 ms	15.60 ms
d10ae0c	1250.02 ms	1253.74 ms	3.72 ms
bee3e88	1232.65 ms	1247.33 ms	14.68 ms

App size

Revision	Plain	With Sentry	Diff
279841c	22.84 KiB	403.19 KiB	380.34 KiB
a176fc4	22.84 KiB	403.24 KiB	380.39 KiB
d26797f	21.58 KiB	682.39 KiB	660.81 KiB
e19cca3	21.58 KiB	669.74 KiB	648.16 KiB
becc941	21.58 KiB	419.82 KiB	398.24 KiB
279841c	22.84 KiB	403.19 KiB	380.35 KiB
c319795	20.76 KiB	431.99 KiB	411.22 KiB
94d8eb3	21.58 KiB	417.86 KiB	396.28 KiB
d10ae0c	20.76 KiB	419.86 KiB	399.10 KiB
bee3e88	22.30 KiB	749.95 KiB	727.64 KiB

Previous results on branch: philprime/file-io-tracking-fix

Startup times

Revision	Plain	With Sentry	Diff
e7b3309	1233.23 ms	1251.71 ms	18.47 ms
ec1acc1	1237.65 ms	1250.54 ms	12.90 ms
e9ec0cb	1221.08 ms	1242.90 ms	21.81 ms
85eb414	1232.55 ms	1255.69 ms	23.14 ms
ae13629	1228.47 ms	1246.39 ms	17.92 ms
6a01c37	1229.94 ms	1243.82 ms	13.88 ms
1f201e0	1231.24 ms	1254.83 ms	23.59 ms
ce89787	1221.44 ms	1237.20 ms	15.76 ms
e0cf4f9	1218.80 ms	1229.96 ms	11.16 ms
3588c99	1242.96 ms	1264.22 ms	21.27 ms

App size

Revision	Plain	With Sentry	Diff
e7b3309	22.31 KiB	779.13 KiB	756.82 KiB
ec1acc1	22.31 KiB	770.06 KiB	747.75 KiB
e9ec0cb	22.31 KiB	770.73 KiB	748.42 KiB
85eb414	22.31 KiB	772.94 KiB	750.62 KiB
ae13629	22.31 KiB	770.92 KiB	748.60 KiB
6a01c37	22.31 KiB	778.67 KiB	756.36 KiB
1f201e0	22.30 KiB	751.69 KiB	729.39 KiB
ce89787	22.31 KiB	770.59 KiB	748.28 KiB
e0cf4f9	22.31 KiB	773.79 KiB	751.48 KiB
3588c99	22.31 KiB	778.24 KiB	755.93 KiB

[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/SentryNSFileManagerSwizzling.m

[brustolin]

Thanks for this investigation.

Since you enable testing for iOS 18.2, we have other I/O tests failing. We could solve them in a different PR that will merge to this one, or disable those tests before merging this to Main.

[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/SentryNSFileManagerSwizzling.m

[codecov]

Codecov Report

Attention: Patch coverage is 69.20635% with 194 lines in your changes missing coverage. Please review.

Project coverage is 90.926%. Comparing base (f5a9f3f) to head (0ca0bcb).
Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
...ance/IO/SentryFileIOTrackingIntegrationTests.swift	62.559%	79 Missing ⚠️
...ormance/IO/DataSentryTracingIntegrationTests.swift	65.306%	68 Missing ⚠️
...formance/IO/SentryFileIOTracker+SwiftHelpers.swift	0.000%	29 Missing ⚠️
...tegrations/Performance/IO/Data+SentryTracing.swift	57.142%	15 Missing ⚠️
Sources/Sentry/SentryFileIOTracker.m	96.666%	0 Missing and 1 partial ⚠️
Sources/Sentry/SentryNSFileManagerSwizzling.m	0.000%	1 Missing ⚠️
...ions/Performance/IO/SentryFileIOTrackerTests.swift	99.090%	1 Missing ⚠️

Additional details and impacted files

@@              Coverage Diff              @@
##              main     #4605       +/-   ##
=============================================
- Coverage   91.112%   90.926%   -0.186%     
=============================================
  Files          623       626        +3     
  Lines        72495     73016      +521     
  Branches     25785     25972      +187     
=============================================
+ Hits         66052     66391      +339     
- Misses        6351      6530      +179     
- Partials        92        95        +3     

Files with missing lines	Coverage Δ
Sources/Sentry/SentryDependencyContainer.m	96.835% <100.000%> (+0.124%)	⬆️
Sources/Sentry/SentryFileIOTrackingIntegration.m	100.000% <100.000%> (ø)
Sources/Sentry/SentryNSDataSwizzling.m	100.000% <100.000%> (ø)
Sources/Sentry/SentryFileIOTracker.m	95.348% <96.666%> (-0.136%)	⬇️
Sources/Sentry/SentryNSFileManagerSwizzling.m	51.923% <0.000%> (-1.019%)	⬇️
...ions/Performance/IO/SentryFileIOTrackerTests.swift	99.502% <99.090%> (+0.101%)	⬆️
...tegrations/Performance/IO/Data+SentryTracing.swift	57.142% <57.142%> (ø)
...formance/IO/SentryFileIOTracker+SwiftHelpers.swift	0.000% <0.000%> (ø)
...ormance/IO/DataSentryTracingIntegrationTests.swift	65.306% <65.306%> (ø)
...ance/IO/SentryFileIOTrackingIntegrationTests.swift	75.396% <62.559%> (-15.766%)	⬇️

... and 15 files with indirect coverage changes

---

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 f5a9f3f...0ca0bcb. Read the comment docs.

[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/SentryNSFileManagerSwizzling.m

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[philipphofmann]

I didn't give this a full pass yet cause I found one potential major issue that could require some significant changes to the PR, which could make plenty of comments obsolete.

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[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/SentryNSDataSwizzling.m
• Sources/Sentry/SentryNSFileManagerSwizzling.m

[philprime]

I've now retried the failing workflow 7 times and keeps failing at different places, but they seem unrelated to my changes (i.e. ANR or timeouts).

@philipphofmann @brustolin would appreciate your assistance in debugging the CI failures.

[philipphofmann]

About CI failures: We see timeouts failing all the time for GH actions. When running those tests locally, they are usually rock solid. This is giving us headaches already for years. The weird thing often is that sometimes we don't see these failures for a while and then they come back even when we don't change the code or the tests. I think we could consider defining a constant for test expectations timeouts which we set to 10 or 30 seconds just for CI. If you have a better idea please let me know. Another idea is to simply disable all the flaky tests, because it's better to have fewer tests we can trust than flaky tests.

[philprime]

So @philipphofmann should we keep this PR open until we have stabilized CI?

Open PRs could be useful to test CI improvements, but it also keeps us from merging this.

[philipphofmann]

So @philipphofmann should we keep this PR open until we have stabilized CI?

Open PRs could be useful to test CI improvements, but it also keeps us from merging this.

Flaky CI shouldn't stop us from merging this PR. We should address these issues separately. But if the CI continuously flakes, maybe it's some changes of this PR and not CI itself.

[philipphofmann]

After we decide on the deduplication logic on spans, I will give this another review cause this can have a significant impact on the PR.

[philipphofmann]

m: We use automatic throughout our performance offering when you only have to flip a flag or set a sample rate. When you manually have to call code we call it manual or leave the automatic keyword out. This could cause confusion.

Suggested change

	/// A `Data` extension that automatically tracks read and write operations with Sentry.
	///
	/// - Note: Methods provided by this extension reflect the same functionality as the original `Data` methods,
	/// but they automatically track the operation with Sentry.
	/// A `Data` extension that tracks read and write operations with Sentry.
	///
	/// - Note: Methods provided by this extension reflect the same functionality as the original `Data` methods,
	/// but they track the operation with Sentry.

[philipphofmann]

m: It would be valuable to clarify which issues in the comment.

[philipphofmann]

h: I'm unsure about this approach. It still could occur that some OS versions switch back to bridging NSData, and then users would get duplicated spans. This also has the downside that people can't use this on older iOS versions when they, for example, disable swizzling. Instead, it would be great if we could implement some deduplication logic for duplicated spans. I still need to figure out how we can do this properly, and will get back to you.