Thread locals are lost after the control is returned from SDK methods to the client code

Describe the feature

This is pretty much a copy of this issue #2142 to be able to continue the discussion. It's been closed for a while, so I guess it's not actively monitored anymore even though the issue still exists.

Basically the issue is that since aws sdk v2 uses netty nio, all thread locals are lost after any async sdk method is completed, that includes spring security context, mdc, servlet request attributes or anything else the developer might have put into a thread local. Unfortunately, there seems to be no way to tell the sdk to preserve this context or extend the sdk in a way that makes it possible. This makes it really hard to use aws sdk v2 in a spring web mvc environment without resorting to migrating to kotlin coroutines or some hacky workarounds (e.g. aspects). Specifying SdkAdvancedAsyncClientOption.FUTURE_COMPLETION_EXECUTOR is also not a solution, since this executor is used after the control has returned from the netty thread pool so the context is already lost at this point.

Use Case

Logging and tracing in a Spring Web MVC environment. Trace and span ids are stored as MDC context (ThreadLocal variables). It's also common to put app-specific data into MDC context to be able to match log lines to a specific request. Currently, all this data are lost after any SDK call, so tracing essentially breaks after an AWS SDK call.

Proposed Solution

No response

Other Information

A shaky workaround I ended up using is to have an aspectj aspect around AWS SDK methods that adds a CompletableFuture handler that restores Thread Locals.

Acknowledgements

[ ] I may be able to implement this feature request
[ ] This feature might incur a breaking change

AWS Java SDK version used

2.25.43

JDK version used

17.0.6

Operating System and version

macOS Sonoma 14.5

aws / aws-sdk-java-v2