perf(core): Prototype breadcrumb persistence as a JSONL append log

[runningcode]

📜 Description

Prototype replacing the vendored Square tape QueueFile with a newline-delimited JSON append log for breadcrumb persistence. Stacked on #5791.

BreadcrumbAppendLog (~200 lines) stores one serialized breadcrumb per line. Appends are a single open/write per flush; bounding is amortized — once the log grows past 2 * maxBreadcrumbs lines it is rewritten down to the newest maxBreadcrumbs behind an atomic renameTo.

AnrProfileManager still uses tape, so no vendored code is deleted yet. That would be a follow-up (its AnrStackTrace uses DataOutputStream, so it needs length-prefixed framing rather than newline framing).

💡 Motivation and Context

Tape is a durable transactional FIFO. Neither consumer needs one:

tape capability	used?
bounded FIFO, evict oldest	yes
append without rewriting the file	yes
peek()/remove() per-item dequeue	never
atomic per-add commit via header write	not needed — see below
crash-safe ring buffer, file doubling, transferTo compaction	incidental

Both PersistingScopeObserver and AnrProfileManager only add, asList, and clear. We're using a transactional queue as an append log, and paying ~1,170 lines of vendored code, ~1,020 lines of tests, a THIRD_PARTY_NOTICES.md entry, and a corrupt-file recovery path for it. Upstream has been archived read-only since Oct 2024 at a 2.0.0-beta1 that never shipped final.

Corruption behaviour also improves. Tape's own header warns that on filesystems without atomic segment writes a mid-write power loss "will contain garbage and the file will be corrupt" — which is why the old code caught IOException and deleted-and-recreated the whole file. A torn trailing JSONL line fails to deserialize and is skipped; every earlier breadcrumb stays readable.

The performance case did not hold up

This is the main finding, and it argues against merging as-is. Measured on an M-series Mac, best of 5 after warmup (BreadcrumbPersistenceBenchmark, @Ignored):

scenario	tape (as shipped)	tape without fsync	JSONL
steady state, 2000 flushes × 1 crumb	8148 ms	25 ms	198 ms
startup, 100 flushes × 20 crumbs	452 ms	26 ms	25 ms
read, 100 reads × 100 crumbs	17.7 ms	17.7 ms	14.8 ms

Against tape as configured today JSONL is 17–41× faster — but nearly all of that is the per-flush fsync, not the format. With the fsync removed, tape is 7.9× faster than JSONL on single-crumb flushes and roughly par on batched ones (JSONL reopens the file per flush; tape holds one RandomAccessFile).

So: dropping the fsync from tape is the cheaper way to get the speed. This PR stands on maintenance burden and corruption behaviour, not throughput.

💚 How did you test it?

BreadcrumbAppendLogTest — 17 cases covering round-trip ordering, bounding, amortized compaction, torn trailing lines, corrupt mid-file lines, logs inherited across instances, legacy-format discard, and newline-bearing breadcrumb data (verifying the JSON writer's \n escaping keeps line framing intact).

Full :sentry, :sentry-android-core, and :sentry-android-replay unit test suites pass. Three tests that seeded breadcrumbs in tape's binary format were updated to write JSONL.

⚠️ Open questions

• Worth it at all? Given the benchmark, the alternative is synchronousWrites(false) + no sync() on tape and keep the library. That's a much smaller diff.
• Format migration. Old breadcrumbs.json files are detected by their first byte and deleted, so one launch post-upgrade has no persisted breadcrumbs. Acceptable? (Breadcrumbs are already discarded on init via resetCache().)
• BreadcrumbAppendLog is public in sentry.api because PersistingScopeObserver is in the same package but tests aren't. Could be package-private with a @TestOnly accessor.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

Decide between this and simply dropping tape's fsync. If this direction is taken: migrate AnrProfileManager to length-prefixed framing, then delete io.sentry.cache.tape and its THIRD_PARTY_NOTICES.md entry.

[linear-code]

JAVA-628

[github-actions]

	Fails
🚫	Please consider adding a changelog entry for the next release.

Instructions and example for changelog

Please add an entry to CHANGELOG.md to the "Unreleased" section. Make sure the entry includes this PR's number.

Example:

## Unreleased

### Performance

- Prototype breadcrumb persistence as a JSONL append log ([#5843](https://github.com/getsentry/sentry-java/pull/5843))

If none of the above apply, you can opt out of this check by adding #skip-changelog to the PR description or adding a skip-changelog label.

Generated by 🚫 dangerJS against 82a1797

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.50.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	330.23 ms	388.45 ms	58.23 ms
Size	0 B	0 B	0 B

Baseline results on branch: no/java-628-batch-scope-persistence

Startup times

Revision	Plain	With Sentry	Diff
1afaf81	334.74 ms	380.29 ms	45.55 ms
5ad5c95	318.13 ms	364.98 ms	46.85 ms
8e8cb90	313.06 ms	356.54 ms	43.48 ms

App size

Revision	Plain	With Sentry	Diff
1afaf81	0 B	0 B	0 B
5ad5c95	0 B	0 B	0 B
8e8cb90	0 B	0 B	0 B