Add support for lambda traces via threadLocal#6295
Conversation
millems
left a comment
There was a problem hiding this comment.
Will async clients be addressed in a separate PR? This won't work for async retries (which are delegated to a retries thread pool), calls that happen within future chaining (which are delegated to a future completion executor thread pool), etc.
We'll want to find where calls might switch threads (i.e. anywhere we're using futures) and then preserve the thread local setting across that thread change.
...re/src/main/java/software/amazon/awssdk/awscore/interceptor/TraceIdExecutionInterceptor.java
Outdated
Show resolved
Hide resolved
.../src/main/java/software/amazon/awssdk/awscore/internal/interceptor/TracingSystemSetting.java
Outdated
Show resolved
Hide resolved
...re/src/main/java/software/amazon/awssdk/awscore/interceptor/TraceIdExecutionInterceptor.java
Outdated
Show resolved
Hide resolved
...rc/test/java/software/amazon/awssdk/awscore/interceptor/TraceIdExecutionInterceptorTest.java
Outdated
Show resolved
Hide resolved
| .responseBody(AbortableInputStream.create(new StringInputStream("{}"))) | ||
| .build()); | ||
|
|
||
| client.allTypes().join(); |
There was a problem hiding this comment.
We should also add a test sending a request in the result future:
client.allTypes()
.thenRun(() -> client.allTypes() /* Did this request have the right trace ID? */)I suspect we'll need to plumb the thread local context to there as well (and clear it, so that reuses of that thread don't have it set).
|
|
flakey integ test is the only failure |
|
This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one. |



Motivation and Context
This implementation uses SLF4J MDC (which uses ThreadLocal under the hood) to read the trace ID value stored in
AWS_LAMBDA_X_TraceIdthat would be set by the Lambda runtime (this would be added later, probably here).