What Does This Do

Add regression test for sync SQS receive response copy context loss
Preserve SQS receive context across AWS SDK response rebuilding
Migrate SQS client tests to JUnit

Motivation

• message handling spans are not attached to an SQS consume/inbound span
• trace continuity from producer to consumer is broken
• extracted upstream context and time-in-queue are lost
• the app still processes messages, but Datadog shows handler work as detached roots or under the wrong active span instead of under the SQS receive/consume flow

Additional Notes

Problem Statement

For sync AWS SDK v2 SQS ReceiveMessage, consumer spans were not created when application code iterated received messages.

The immediate cause was that ReceiveMessageResponse.messages() was not returning a TracingList. That wrapping only happens when the instrumentation can find the original QueueUrl attached to the ReceiveMessageResponse.

The old code attached QueueUrl in afterExecution, but afterExecution.context.response() is not the final response instance returned to user code. AWS SDK core rebuilds the response before returning it, in BaseClientHandler.attachHttpResponseToResult():

return ((response, httpFullResponse) ->
    (OutputT) response.toBuilder().sdkHttpResponse(httpFullResponse).build());

So the queue URL was attached to the pre-rebuild response, while user code called messages() on the rebuilt response. The context lookup missed, the list was not wrapped, and no consumer spans were created.

Why tests didn't catch it

The old tests only proved that a Sqs.ReceiveMessage span existed, for example in this assertTraces block. They did not prove it was created during application/user iteration.

The new test creates a span inside the user message-iteration callback and verifies that this span is a child of the SQS consumer span.

The old test could see Sqs.ReceiveMessage because it was created during MessageMD5ChecksumInterceptor.afterExecution. TracingExecutionInterceptor.afterExecution and MessageMD5ChecksumInterceptor.afterExecution run in the same AWS SDK afterExecution interceptor phase, with the same afterExecution.context.response() object. The old Datadog interceptor attached QueueUrl to that exact pre-rebuild response instance, so when the checksum interceptor called messages() on the same object, our instrumentation found QueueUrl and returned a TracingList.

User code saw a different object: the final response instance created by BaseClientHandler.attachHttpResponseToResult(). In the old implementation, that final response did not have QueueUrl attached, so user-code messages() was not wrapped.

Solution

Move QueueUrl capture from afterExecution to modifyResponse in TracingExecutionInterceptor.

modifyResponse is the right hook because it runs after unmarshalling, while both the original ReceiveMessageRequest and the pre-rebuild ReceiveMessageResponse are available, but before AWS SDK core creates the final response copy.

If QueueUrl is captured in afterExecution, that final response copy already exists. At that point we can still attach QueueUrl to afterExecution.context.response(), but the SDK has already called toBuilder() and build(), so the builder advices have already missed their chance to carry the value to the response instance returned to user code.

The instrumentation stores QueueUrl on the pre-rebuild ReceiveMessageResponse, then propagates it through the SDK copy path:

pre-rebuild response -> response builder -> final response returned to user code

This is done with two advices:

• ReceiveMessageResponse.toBuilder() copies QueueUrl from the response context store to the builder context store.
• ReceiveMessageResponse$BuilderImpl.build() copies QueueUrl from the builder context store to the newly built response.

After that, when user code calls messages() on the final response instance, the advice can find QueueUrl, return a TracingList, and create the SQS consumer span during user message iteration.

The change also marks MessageMD5ChecksumInterceptor.afterExecution as SDK-internal access, so its internal messages() call does not wrap the list or create consumer spans during checksum verification. Consumer spans are created when application code consumes the messages.

Contributor Checklist

• Format the title according to the contribution guidelines
• Assign the type: and (comp: or inst:) labels in addition to any other useful labels
• Avoid using close, fix, or any linking keywords when referencing an issue
  Use solves instead, and assign the PR milestone to the issue
• Update the CODEOWNERS file on source file addition, migration, or deletion
• Update public documentation with any new configuration flags or behaviors
• Add your completed PR to the merge queue by commenting /merge. You can also:
  • Customize the commit message associated with the merge with /merge --commit-message "..."
  • Remove your PR from the merge queue with /merge -c
  • Skip all merge queue checks with /merge -f --reason "reason"; please use this judiciously, as some checks do not run at the PR-level
  • Get more information in this doc

Jira ticket: APMS-19562