fix(telemetry): Resolve default org via ValueSource at execution (GRADLE-82)#1263
Merged
Conversation
runningcode
requested review from
0xadam-brown,
adinauer,
markushi and
romtsn
as code owners
June 4, 2026 11:03
runningcode
force-pushed
the
no/config-cache-telemetry-org
branch
from
June 4, 2026 12:43
ce7be81 to
a5eb5b8
Compare
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
…DLE-82) When telemetry is enabled (the default), the plugin resolved the default Sentry organization and CLI version at configuration time via two ValueSources that each spawned a sentry-cli process. Because they were `.get()`-ed during configuration, Gradle tracked them as configuration inputs and re-ran both processes on every configuration-cache-hit build, adding significant overhead even when no Sentry task executed. Replace them with a single SentryOrgValueSource that is queried lazily on the first tracked task, so the sentry-cli process runs during execution and stays off the configuration phase. The CLI version now comes straight from BuildConfig. Co-Authored-By: Claude Opus 4.8 <[email protected]>
Co-Authored-By: Claude Opus 4.8 <[email protected]>
attachDefaultOrg() runs on the first tracked task and may be invoked concurrently from parallel task threads. Replace the plain Boolean flag and its check-then-set with an AtomicBoolean compareAndSet so the attach body runs exactly once and the flag's visibility is guaranteed across threads. This is a robustness tightening, not a fix for duplicate sentry-cli processes: the process is spawned inside the SentryOrgValueSource, which Gradle evaluates at most once per build regardless of this flag. Co-Authored-By: Claude Opus 4.8 <[email protected]>
runningcode
force-pushed
the
no/config-cache-telemetry-org
branch
from
June 9, 2026 07:26
a5eb5b8 to
0ad3a9e
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 0ad3a9e. Configure here.
| } | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Parallel tasks miss default org
Low Severity
attachDefaultOrg uses compareAndSet so only one caller runs orgProvider, while other concurrent startTask calls return immediately. If Gradle runs multiple telemetry-wrapped tasks in parallel, siblings can start spans before the winning thread finishes sentry-cli info and updates the scope user, so early events may lack the default organization.
Reviewed by Cursor Bugbot for commit 0ad3a9e. Configure here.
This was referenced Jun 11, 2026
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
2 participants
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.
Summary
When telemetry is enabled (the default), the plugin resolved the default Sentry organization and CLI version during the configuration phase via two
ValueSources (SentryCliInfoValueSourcerunningsentry-cli info, andSentryCliVersionValueSourcerunningsentry-cli --version). Because both were.get()-ed during configuration, Gradle tracked them as configuration inputs and re-evaluated them on every configuration-cache-hit build — spawning twosentry-cliprocesses on every build even when no Sentry task ran. On a ~100-module project this added ~38% configuration overhead.This replaces them with a single
SentryOrgValueSourcethat is queried lazily on the first tracked task, so thesentry-cliprocess runs during execution and stays off the configuration phase. The CLI version now comes directly fromBuildConfig.CliVersion.This is one of two PRs splitting the config-cache work; the companion PR (#GRADLE-70) makes the sentry-cli path resolution config-cache friendly. Whichever lands second will drop the now-unused
cliExecutableparameter still threaded throughconfigure().Behavioral note: when the default org attaches
Previously the default org was resolved at configuration time and set on the telemetry scope inside
start()(attaskGraph.whenReady), so it was attached before execution began. Now it attaches lazily on the first telemetry-tracked task to execute (viaattachDefaultOrg(), called fromstartTask).Every Sentry upload task is telemetry-wrapped (
withSentryTelemetry→startTask) — mappings, native symbols, app artifact, source bundle, the ProGuard UUID/dependency-report tasks, etc. — so any build that actually does a Sentry upload runs at least one tracked task and gets the default org attached. The only events that would miss the default org are those captured strictly before any tracked task runs (e.g. a failure during the configuration phase). That's an inherent and acceptable consequence of moving thesentry-cli infocall off the configuration phase, which is the whole point of this change; an explicitly configured org is still set eagerly instart()and is unaffected.Fixes GRADLE-82
🤖 Generated with Claude Code