perf(core): [Logs and Metrics Enable Flags 11] Avoid unused Logs worker thread

[adinauer]

PR Stack (Logs and Metrics Enable Flags)

• feat(core): Remove Logs and Metrics enable flags #5939
• feat(logback): [Logs and Metrics Enable Flags 1] Add Logs opt-in #5940
• feat(log4j2): [Logs and Metrics Enable Flags 2] Add Logs opt-in #5941
• feat(jul): [Logs and Metrics Enable Flags 3] Add Logs opt-in #5942
• feat(android): [Logs and Metrics Enable Flags 4] Add Timber Logs opt-in #5943
• feat(android): [Logs and Metrics Enable Flags 5] Add Logcat Logs opt-in #5945
• feat(spring): [Logs and Metrics Enable Flags 6] Add logging Logs opt-in for Spring Boot #5946
• feat(core): [Logs and Metrics Enable Flags 7] Remove Logs enable flag #5947
• feat(android): [Logs and Metrics Enable Flags 8] Warn for legacy Logs metadata #5949
• feat(core): [Logs and Metrics Enable Flags 9] Warn for legacy Logs configuration #5950
• feat(spring): [Logs and Metrics Enable Flags 10] Warn for legacy Logs property #5951
• perf(core): [Logs and Metrics Enable Flags 11] Avoid unused Logs worker thread #5952
• feat(core): [Logs and Metrics Enable Flags 12] Remove Metrics enable flag #5953
• feat(android): [Logs and Metrics Enable Flags 13] Warn for legacy Metrics metadata #5954
• feat(core): [Logs and Metrics Enable Flags 14] Warn for legacy Metrics configuration #5955
• feat(spring): [Logs and Metrics Enable Flags 15] Warn for legacy Metrics property #5956
• perf(core): [Logs and Metrics Enable Flags 16] Avoid unused Metrics worker thread #5957
• fix(jul): [Logs and Metrics Enable Flags 17] Preserve null-message records #5960
• docs: [Logs and Metrics Enable Flags 18] Update options guidance #5961
• fix(android): [Logs and Metrics Enable Flags 19] Read Timber option lazily #5964
• fix(core): [Logs and Metrics Enable Flags 20] Make migration warnings visible #5966
• ref(logging): [Logs and Metrics Enable Flags 21] Rename Logs opt-ins #5970

---

📜 Description

Tracks whether LoggerBatchProcessor has accepted its first Log item. Before that point, empty flushes and restart closes do not schedule processor work. Normal close still closes the executor directly.

After the first accepted item, batching, flushing, and restart-close behavior remain unchanged. Items rejected because of shutdown or queue capacity do not mark the processor as used.

💡 Motivation and Context

The aggregate Logs enable flag has been removed, so every SDK client now owns a logger batch processor. Without this guard, lifecycle flushes—particularly Android background callbacks—can start a worker thread even when the application never captures a Log.

💚 How did you test it?

• ./gradlew :sentry:test :sentry-android-core:testReleaseUnitTest
• ./gradlew spotlessApply apiDump
• Added core tests for construction, empty flush, close, restart close, rejected items, and behavior after first use
• Added an Android background callback test before first use

📝 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

Remove the aggregate Metrics enable flag.

#skip-changelog

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.

[sentry]

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	314.02 ms	352.98 ms	38.96 ms
Size	0 B	0 B	0 B

Baseline results on branch: feat/warn-legacy-logs-spring

Startup times

Revision	Plain	With Sentry	Diff
c2e4325	310.06 ms	363.22 ms	53.16 ms

App size

Revision	Plain	With Sentry	Diff
c2e4325	0 B	0 B	0 B

Previous results on branch: perf/logs-batch-thread-first-use

Startup times

Revision	Plain	With Sentry	Diff
31a945a	307.74 ms	351.86 ms	44.11 ms

App size

Revision	Plain	With Sentry	Diff
31a945a	0 B	0 B	0 B

[sentry]

Bug: A race condition between add() and close() can cause log events to be lost if an event is added after the executor has been shut down but before the queue is drained.
_{Severity: MEDIUM}

Suggested Fix

Synchronize access to the shutdown state and executor operations. For example, use a synchronized block around the shutdown check and item queuing in add() and the entire close() method to ensure that add() cannot proceed while a shutdown is in progress.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: sentry/src/main/java/io/sentry/logger/LoggerBatchProcessor.java#L78-L80

Potential issue: A race condition exists between the `add()` and `close()` methods in
`LoggerBatchProcessor`. A thread calling `add()` can pass the `isShuttingDown` check
just before another thread calling `close()` sets `isShuttingDown` to true and shuts
down the `executorService`. The first thread then adds a log event to the queue but
fails to schedule a flush task because the executor is closed, leading to a
`RejectedExecutionException`. The event remains in the queue but is never processed
because the queue drain in `close()` may have already completed, resulting in the silent
loss of the log event.

Also affects:

• sentry/src/main/java/io/sentry/logger/LoggerBatchProcessor.java:116~124

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[runningcode]

This is valid. The transactions are not atomic.

[runningcode]

This seems like a bugfix unrelated to the stack. Can we make this an independent PR?