Skip to content

traceId not being logged inside of ExchangeFilterFunction.ofResponseProcessor #33149

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
russelbulanon opened this issue Jul 4, 2024 · 1 comment
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply theme: observability An issue related to observability and tracing

Comments

@russelbulanon
Copy link

I want to log WebClient's request & response and have used ExchangeFilterFunction.orRequestProcessor to log the request and traceId is still being logged in here, but for the response, traceId is not being logged using ExchangeFilterFunction.ofResponseProcessor

Sample logs
image

Sample project to reproduce the issue
https://github.com/russelbulanon/tracing-demo

Versions:

  • Java: 17
  • Spring boot: 3.3.1
  • Gradle: 8.8
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Jul 4, 2024
@bclozel bclozel transferred this issue from spring-projects/spring-boot Jul 4, 2024
@bclozel bclozel added in: web Issues in web modules (web, webmvc, webflux, websocket) theme: observability An issue related to observability and tracing labels Jul 4, 2024
@bclozel bclozel self-assigned this Jul 4, 2024
@bclozel bclozel added status: invalid An issue that we don't feel is valid in: web Issues in web modules (web, webmvc, webflux, websocket) and removed status: waiting-for-triage An issue we've not yet triaged or decided on in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jul 9, 2024
@bclozel
Copy link
Member

bclozel commented Jul 9, 2024

Thanks for reaching out and for the minimal repro.

While not being ideal, this is unfortunately the best we can do here. We we do instrument the DefaultWebClient, we start the observation before creating the request, and stop it when the response is fully read/consumed. This properly times the exchange and produces the expected metrics.

On the other hand, the current observation context is set up for upstream operators and cannot be applied to operators further down the line. This explains why the request processor shows the traceId but the response processor doesn't.
I couldn't find another place to set the context value; Mono<ClientResponse> exchange() is a public method and while it's been deprecated for a while, we cannot assume that developers will chain with another method of ours.

@bclozel bclozel closed this as not planned Won't fix, can't repro, duplicate, stale Jul 9, 2024
@bclozel bclozel added status: declined A suggestion or change that we don't feel we should currently apply and removed status: invalid An issue that we don't feel is valid labels Jul 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) status: declined A suggestion or change that we don't feel we should currently apply theme: observability An issue related to observability and tracing
Projects
None yet
Development

No branches or pull requests

3 participants