Skip to content

Conversation

@laurit
Copy link
Contributor

@laurit laurit commented Aug 19, 2025

Resolves #14441

Reporting partial batch failures requires using SQSBatchResponse which is not available in 2.2 that we currently have library instrumentation for. This PR adds a new library instrumentation for 3.11. This is unusual since for other instrumentations we don't have library instrumentations for multiple versions. I'm looking for feedback on how we should handle this. Keep javaagent at 2.2 and move library to 3.11? If we are going to do that then changing the package name is going to break existing code, is that fine or should we do some sort of deprecation cycle? If we are going to remove the 2.2 module should we try to do maven relocation to new coordinates (have we done this before)? cc @trask
Bumping the library version would also unblock #8642

@laurit laurit requested a review from a team as a code owner August 19, 2025 17:23
@trask
Copy link
Member

trask commented Aug 19, 2025

I like the idea of a deprecation cycle for the 2.2 library module where we mark all the public classes as deprecated

I'd suggest keeping the Java agent instrumentation at 2.2 to stay consistent with https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/VERSIONING.md#dropping-support-for-older-library-versions

@laurit
Copy link
Contributor Author

laurit commented Aug 19, 2025

I like the idea of a deprecation cycle for the 2.2 library module where we mark all the public classes as deprecated

I think the only open question would be whether we introduce a new module that is shared between the deprecate 2.2 and 3.1 or move all shared internal classes to 3.1 and make 2.2 depend on 3.1. Perhaps the common module would be better since we could keep compiling it against 2.2 and agent could depend on it instead of the new 3.1 module.

I'd suggest keeping the Java agent instrumentation at 2.2 to stay consistent with https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/VERSIONING.md#dropping-support-for-older-library-versions

This shouldn't be a problem since the agent only uses internal classes from the library module which didn't change.

@trask
Copy link
Member

trask commented Aug 19, 2025

👍

@trask trask merged commit fd74eb8 into open-telemetry:main Aug 22, 2025
168 of 169 checks passed
lukeina2z added a commit to aws-observability/aws-otel-java-instrumentation that referenced this pull request Oct 27, 2025
This PR updates the upstream dependency OpenTelemetry Java Agent to their 2025 Sep. release version 2.20.1 (opentelemetry-instrumentation:2.20.1). By doing so, the following upstream OpenTelemetry dependencies are automatically updated along with the Java Agent: opentelemetry-api: 1.54.1 opentelemetry-sdk: 1.54.1 opentelemetry-semconv: 1.37.0 Conflicts between the ADOT patch and the two upstream PRs below are resolved in this PR. Rename lambda instrumentation helper class open-telemetry/opentelemetry-java-instrumentation#14371 Let AWS Lambda SQS handlers report partial batch failures open-telemetry/opentelemetry-java-instrumentation#14468 Tests Performed Unit tests: ./gradlew build test Smoke/contract tests: ./gradlew appsignals-tests:contract-tests:contractTests Manual E2E tests: Spring Boot EC2 sample app Java Lambda function Spring Boot web application hosted on AWS Lambda By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants