Repository navigation
fix(tracing): Stop idle spans from keeping idle transactions alive until their deadline (JAVA-795) - #6396
Open
0xadam-brown wants to merge 1 commit into
Open
fix(tracing): Stop idle spans from keeping idle transactions alive until their deadline (JAVA-795)#63960xadam-brown wants to merge 1 commit into
0xadam-brown wants to merge 1 commit into
Conversation
📲 Install BuildsAndroid
|
0xadam-brown
force-pushed
the
fix/sentry-nav-traced-idling
branch
from
October 27, 2026 16:19
7c18f01 to
b2fddd4
Compare
…til their deadline (JAVA-795) An idle span (SpanOptions.isIdle) is meant to be finished by its parent transaction when the transaction finishes. Before this commit, SentryTracer treated an unfinished idle span as blocking. Creating one canceled the idle timer; SentryTracer.hasAllChildrenFinished() counted it as unfinished; and the timer never restarted. As a consequence, any idle transaction that i) waited for its children (i.e., all Android idle transactions, including ui.load and nav transactions) and ii) had an unfinished idle span was kept alive until its deadline (30 s by default), causing it to be reported as DEADLINE_EXCEEDED even though in most cases no actual work was keeping the transaction alive. **Current producers of idle spans** SentryTraced is the SDK's only producer of idle spans, so the effects mentioned above are limited to idle transactions that, prior to this commit, contained a span from SentryTraced. (The issue has been with SentryTraced from the beginning – see #2507).
0xadam-brown
force-pushed
the
fix/sentry-nav-traced-idling
branch
from
October 27, 2026 16:27
b2fddd4 to
b1bdbbb
Compare
0xadam-brown
marked this pull request as ready for review
October 27, 2026 16:28
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
📜 Description
An idle span (
SpanOptions.isIdle()) is meant to be finished by its parent transaction when the transaction finishes. Before this PR,SentryTracertreated an unfinished idle span as blocking. Creating one canceled the idle timer; SentryTracer.hasAllChildrenFinished() counted it as unfinished; and the timer never restarted.As a consequence, any idle transaction that i) waited for its children (i.e., all Android idle transactions, including ui.load and nav transactions) and ii) had an unfinished idle span, was kept alive until its deadline (30 s by default). That in turn caused the transaction to be reported as DEADLINE_EXCEEDED even though in most cases no actual work was keeping the transaction alive.
💡 Motivation and Context
I discovered this issue while implementing multi-Activity support for Nav3 (see #6301).
Current producers of idle spans
SentryTracedis the SDK's sole producer of idle spans in sentry-java (link), so the effects mentioned above are limited to idle transactions that, prior to this commit, contained a span from SentryTraced.(The issue has been with SentryTraced from the beginning.)
💚 How did you test it?
Unit tests + had my clanker verify pre- and post-fix behavior via the Android sample app.
📝 Checklist
sendDefaultPIIis enabled.🔮 Next steps