feat(auto-install): Fail the build on OpenTelemetry version downgrades#268
Merged
adinauer merged 5 commits intoJul 14, 2026
Conversation
Sentry's sentry-opentelemetry-* artifacts are built and tested against specific OpenTelemetry versions. When another dependency management mechanism (most commonly Spring Boot, via spring-boot-starter-parent or an imported spring-boot-dependencies BOM) forces OpenTelemetry below those versions, it happens silently and can cause ClassNotFoundException / NoSuchMethodError at runtime. Detect this at build time: resolve the OpenTelemetry versions the project's sentry-opentelemetry-* artifacts require and compare them against the versions actually resolved. If any resolved version is a downgrade, fail the build with actionable guidance to import sentry-opentelemetry-bom (noting Maven's first-declaration-wins ordering when Spring Boot is present). Only OpenTelemetry modules that a sentry-opentelemetry-* artifact requires are inspected, so unrelated OpenTelemetry usage is never flagged. The check runs automatically in the lifecycle participant and can be disabled with skipValidateOpenTelemetryVersions. Adds a SENTRY_validateOpenTelemetryVersions telemetry tag. This replaces an earlier approach that auto-installed the BOM: in Maven a late-injected import-scope BOM is a no-op, and rewriting inherited dependencyManagement is too surprising. Mirrors sentry-android-gradle-plugin#1350. Co-Authored-By: Claude <[email protected]>
Contributor
|
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
lbloder
reviewed
Jul 7, 2026
The OpenTelemetry version check was nested inside the auto-install guard, so it never ran when skipAutoInstall was enabled. This is wrong — a project that manages its own Sentry dependencies but has a Spring Boot BOM downgrading OpenTelemetry should still get the build-time failure. Move dependency resolution before the auto-install guard so both auto-install and the OTel check can use it. The OTel check now runs independently, gated only by its own skipValidateOpenTelemetryVersions flag. Also remove the sentryVersion parameter from OpenTelemetryVersionChecker .check() — it now derives the version from the resolved sentry-opentelemetry-* artifact since it was only used in the error message. Co-Authored-By: Claude <[email protected]>
Fix the docs URL to match the actual path in the docs PR: /platforms/java/opentelemetry/troubleshooting/ Expand the changelog entry to explain the check, that it runs independently of auto-install, and how to disable it. Co-Authored-By: Claude <[email protected]>
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.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit eb9fb16. Configure here.
… are disabled Previously, dependency resolution always ran even when both skipAutoInstall and skipValidateOpenTelemetryVersions were set. This meant customers had no way to fully opt out if resolution itself caused issues. Skip resolution entirely when neither feature needs it, giving customers a clean escape hatch. Co-Authored-By: Claude <[email protected]>
When the global skip flag is set, both auto-install and OTel version check are disabled, so the new early-exit message fires instead of the auto-install-specific one. Co-Authored-By: Claude <[email protected]>
adinauer
merged commit Jul 14, 2026
af178f6
into
side-quest/detect-bom-version-for-install
11 checks passed
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.
Builds on top of #265. Maven port of getsentry/sentry-android-gradle-plugin#1350 (which itself is stacked on the SAGP equivalent of #265, getsentry/sentry-android-gradle-plugin#1349).
What
Fails the build when the OpenTelemetry versions resolved for a project are downgraded below what Sentry's
sentry-opentelemetry-*artifacts were built and tested against.Why
Sentry's OpenTelemetry artifacts declare the exact OpenTelemetry versions they require. When another dependency management mechanism — most commonly Spring Boot (via
spring-boot-starter-parentor an importedspring-boot-dependenciesBOM) — forces OpenTelemetry below those versions, it happens silently (the user never declares an OTel version). Running against the mismatched versions can throwClassNotFoundException/NoSuchMethodErrorat runtime. This surfaces the problem at build time with actionable guidance instead.This replaces an earlier approach that auto-installed the BOM (previous PR #266). In Maven a late-injected import-scope BOM is a no-op (BOM imports are flattened during effective-model building, before
afterProjectsRead), and rewriting inheriteddependencyManagementin place is too surprising. Detecting-and-failing is the more honest behavior — same conclusion as SAGP #1350.How it works
sentry-opentelemetry-*artifact.sentry-opentelemetry-*artifact to determine the OpenTelemetry versions it requires (declared dependencies + its own dependency management), then compares against the versions actually resolved on the project. A resolved version lower than the required version is a downgrade.sentry-opentelemetry-*artifact requires are inspected, so unrelated OpenTelemetry usage is never flagged. Unparseable versions are skipped.<dependencyManagement>import forsentry-opentelemetry-bomat the resolved Sentry version, noting Maven's first-declaration-wins ordering when Spring Boot is present.Config
Opt out with
<skipValidateOpenTelemetryVersions>true</skipValidateOpenTelemetryVersions>. Adds aSENTRY_validateOpenTelemetryVersionstelemetry tag.Phase / placement
Implemented in the lifecycle participant (runs before any phase, automatically) rather than as an opt-in
validate-phase mojo, so users get protected by default — matching SAGP #1350's automatic, default-on behavior.Open items (mirroring SAGP #1350)
.../platforms/java/tracing/instrumentation/opentelemetry/troubleshooting/) and must resolve to a live page before release.Tests
OpenTelemetryVersionCheckerTest): downgrade detection (match / upgrade / not-resolved / alpha / unparseable), eligibility gate, and failure-message content (mismatch line, BOM snippet, opt-out, Spring Boot ordering note).OpenTelemetryVersionCheckTestIT): build fails on a Spring Boot parent downgrade with the guidance message; succeeds when not downgraded; succeeds when disabled; no-op without a Sentry OpenTelemetry dependency.Co-authored with Claude.