Closed wpan1 closed 4 years ago
Thanks for reporting - just for reference, it reminds me of https://github.com/openzipkin/zipkin-aws/issues/147 but now for v2.
Though found we do have a comment mentioning retries that may not reflect reality
@wpan1 By the way what version of the AWS sdk are you using? Want to confirm it's not something that changed in a version update
I'm using 2.10.73
Though found we do have a comment mentioning retries that may not reflect reality
Yeah we thought that was odd since the javadoc on AWS SDK's ExecutionInterceptor#modifyHttpRequest
does not indicate potential for multiple invocations (whereas it does for some other methods)
Investigated the SDK and I don't think it's currently possible to instrument it such that we can model each retry as a separate span as we currently are trying to do. I filed a feature request to see if the SDK can gain a knob for this
https://github.com/aws/aws-sdk-java-v2/issues/1741
I guess an NPE is worse than not being able to model the retries - @adriancole do you think we can switch to just having a single client span?
single client span happens in other instrumentation who are blind to retry handling, so sounds fine to me until a knob becomes available
Hey 👋,
Using
TracingExecutionInterceptor
withSqsAsyncClient
can throw a NPE during retries when there is a HTTP 500 response.TracingExecutionInterceptor
throws NPE inbeforeUnmarshalling()
whenclientSpan
is null. This happens during retries asmodifyHttpRequest()
is only called once initially to setup theclientSpan
. Further retry calls do not hitmodifyHttpRequest()
, which means oncebeforeUnmarshalling()
clearsclientSpan
, the consequent retry responses have a nullclientSpan
.Here is a sandbox repo and test to help you reproduce the error.
Stack trace: