Using tags could also be handy for #15664 where currently context is kept in maps. Though there context for the current span is needed but here we keep the parent context.

Using tags could also be handy for #15664 where currently context is kept in maps. Though there context for the current span is needed but here we keep the parent context.

Actually storing context on the request tag doesn't work for EventListener as the call object available in the EventListener is immutable and references the original request and not the modified request with span context from the TracingInterceptor. I did try using request tag in #15664 but it did not work for this reason.

It was confusing to me first as tags work from one interceptor to next as chain contains the modified request and I thought similarly it should work for event listener but event listener references the immutable call object which only contains the original request.

Here it worked when request to context map was used in earlier solution as the ContextInterceptor that references the stored context is the very first interceptor so it ensures that chain.request() would return the original request. With the new solution there's no dependence on original request as all modified request will also contain the tags from the original request.

Actually storing context on the request tag doesn't work for EventListener as the call object available in the EventListener is immutable and references the original request and not the modified request with span context from the TracingInterceptor. I did try using request tag in #15664 but it did not work for this reason.

I'd imagine that these issues could be overcome by adding a mutable tag to the request when the call is created an updating it with the context for the created span once it becomes available.