Skip to content

Nightly dependency update: OpenTelemetry 2.33.1/1.62.1 - #1485

Open
aws-application-signals-bot wants to merge 5 commits into
mainfrom
nightly-dependency-updates
Open

aws-application-signals-bot wants to merge 5 commits into
mainfrom
nightly-dependency-updates

Conversation

@aws-application-signals-bot

@aws-application-signals-bot aws-application-signals-bot commented Oct 24, 2026 •

Copy link
Copy Markdown
Collaborator

Automated update of OpenTelemetry dependencies.

Build Status: ❌ failure

Updated versions:

Upstream releases with breaking changes:
Note: the mechanism to detect upstream breaking changes is not perfect. Be sure to check all new releases and understand if any additional changes need to be addressed.

@aws-application-signals-bot
aws-application-signals-bot requested a review from a team as a code owner October 24, 2026 04:03
@github-actions

github-actions Bot commented Oct 24, 2026 •

Copy link
Copy Markdown

Claude finished @aws-application-signals-bot's task in 42s —— View job


Claude PR Review

  • Check prior review comments for dedup — no prior reviews/comments found
  • Read the PR diff
  • Inspect changed files
  • Investigate the failing build — unable to fetch workflow logs from this runner
  • Post findings (if any) — no new findings

Summary

This is a mechanical nightly dependency bump:

  • .github/patches/versions — OTEL_JAVA_INSTRUMENTATION_VERSION: v2.32.0 → v2.33.0 (contrib was already v1.61.0 on main, so despite the PR title that line is unchanged)
  • dependencyManagement/build.gradle.kts — otelVersion: 2.32.0 → 2.33.0, otelSnapshotVersion: 2.33.0 → 2.34.0

The two changes are consistent with each other, and the contrib artifact coordinates (opentelemetry-aws-xray:1.61.0-adot1, opentelemetry-aws-resources:1.61.0-alpha) already match the target contrib release — no further pins to update.

Note on the build failure

The linked build run 40058804524 is marked failed, but I don't have access to fetch its logs from this environment. Common causes for upstream version bumps in this repo are muzzle/javaagent compile breaks against renamed/removed instrumentation internals in 2.33.0, or snapshot-repo availability for the new 2.34.0-SNAPSHOT. Worth checking the OTel Java Instrumentation 2.33.0 release notes for breaking internal API changes against the awsagentprovider/instrumentation modules before merging.

No inline comments to add — nothing in the diff itself warrants blocking feedback.
· Branch: nightly-dependency-updates

@aws-application-signals-bot aws-application-signals-bot changed the title Nightly dependency update: OpenTelemetry 2.33.0/1.61.0 Nightly dependency update: OpenTelemetry 2.33.1/1.61.0 Oct 28, 2026
@aws-application-signals-bot aws-application-signals-bot changed the title Nightly dependency update: OpenTelemetry 2.33.1/1.61.0 Nightly dependency update: OpenTelemetry 2.33.1/1.62.0 Nov 4, 2026
@aws-application-signals-bot aws-application-signals-bot changed the title Nightly dependency update: OpenTelemetry 2.33.1/1.62.0 Nightly dependency update: OpenTelemetry 2.33.1/1.62.1 Nov 7, 2026
@github-actions

github-actions Bot commented Nov 9, 2026 •

Copy link
Copy Markdown

Claude finished @liustve's task in 1m 19s —— View job


Claude PR Review

  • Check prior review comments for dedup — none found
  • Read the PR diff
  • Inspect changed files
  • Investigate the failing build
  • Post findings

Summary

Mechanical nightly bump:

  • .github/patches/versions — OTEL_JAVA_INSTRUMENTATION_VERSION: v2.32.0 → v2.33.1, OTEL_JAVA_CONTRIB_VERSION: v1.61.0 → v1.62.1
  • dependencyManagement/build.gradle.kts — otelVersion 2.32.0 → 2.33.1, otelSnapshotVersion 2.33.0 → 2.34.0, and the two io.opentelemetry.contrib:* artifact pins moved to 1.62.1-adot1 / 1.62.1-alpha

The two files are internally consistent. No further pins require updating.

Why the build is failing (root cause)

The failure is not in the Gradle code, but in applying .github/patches/opentelemetry-java-contrib.patch against the new upstream v1.62.1 tag (log). Three hunks reject:

  1. aws-xray/.../AwsXrayRemoteSampler.java — both hunks @@235 and @@243 FAILED. The lines the patch anchors on have moved/changed between contrib 1.61.0 and 1.62.1, so neither hunk applies.
  2. aws-xray/.../XrayRulesSampler.java — hunk Create release-notes folder #5 @@335 FAILED (hunks 1–4, 6, 7 still apply with offsets). Context around line 335 drifted.
  3. version.gradle.kts — hunk Update to latest agent dependency. #1 FAILED because the patch is still anchored on:
    -val stableVersion = "1.61.0"
    -val alphaVersion = "1.61.0-alpha"
    +val stableVersion = "1.61.0-adot1"
    +val alphaVersion = "1.61.0-alpha-adot1"
    
    but upstream v1.62.1's version.gradle.kts now reads 1.62.1 / 1.62.1-alpha. This is purely a version-string drift and is the most straightforward of the three to fix.

Because the patch step fails, all downstream jobs that depend on it (di-contract-tests, serviceevents-contract-tests, the main PR build) are blocked. The Gradle artifact coordinate updates in dependencyManagement/build.gradle.kts are consistent with the target version — they are not the cause.

Recommendation

Update .github/patches/opentelemetry-java-contrib.patch to apply cleanly against the v1.62.1 tag:

  • Rebase/retarget version.gradle.kts hunk to the new 1.62.1/1.62.1-alpha values (producing 1.62.1-adot1/1.62.1-alpha-adot1).
  • Regenerate the two Java hunks (AwsXrayRemoteSampler.java @@235/@@243 and XrayRulesSampler.java @@335) against upstream v1.62.1. The .rej files produced in the failing job show exactly which original lines no longer exist and need re-anchoring.

Worth skimming the contrib v1.62.0 and v1.62.1 release notes for AWS X-Ray sampler changes to understand whether the patched behavior (the empty-statistics early-return and the getRequestCount() > 0 filter) is still needed or has been absorbed upstream.

No inline comments posted — the diff itself is clean; the issue is in a file not touched by this PR.
· Branch: nightly-dependency-updates

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants