| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
Track whether the logger batch processor has accepted an item and skip empty flush and restart-close scheduling until then. This prevents SDK initialization and Android background callbacks from starting a worker thread when Logs are unused. Co-Authored-By: Claude <noreply@anthropic.com>
📲 Install BuildsAndroid
|
Sorry, something went wrong.
Performance metrics 🚀
Baseline results on branch: feat/warn-legacy-logs-springStartup times
App size
Previous results on branch: perf/logs-batch-thread-first-useStartup times
App size
|
Sorry, something went wrong.
| queue.offer(logEvent); | ||
| hasAcceptedItem = true; | ||
| maybeSchedule(false); |
There was a problem hiding this comment.
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
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 AgentReview 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:
Did we get this right? 👍 / 👎 to inform future reviews.
Sorry, something went wrong.
There was a problem hiding this comment.
This is valid. The transactions are not atomic.
Sorry, something went wrong.
There was a problem hiding this comment.
This seems like a bugfix unrelated to the stack. Can we make this an independent PR?
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
PR Stack (Logs and Metrics Enable Flags)
📜 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?
📝 Checklist
🔮 Next steps
Remove the aggregate Metrics enable flag.
#skip-changelog