Header added to request in rhai does not propagated into logs trace_id field

[kindermax]

Describe the bug

Router version: v1.43.1

I use rhai to insert a x-trace-id header into request. Then I expect value of this header to be a trace_id in logs.

To Reproduce

Here I use x-trace-id to propagate header value to logs. If x-trace-id present in headers from browser request - it works fine. But if I add x-trace-id header in rhai script - value does not propagated.

telemetry:
  exporters:
    tracing:
      propagation:
        request:
          header_name: x-trace-id
    logging:
      stdout:
        enabled: true
        format:
           json:
             display_level: true
             display_timestamp: true
             display_trace_id: true
             display_span_id: true

rhai script

fn supergraph_service(service) {
    let adapt_request_id = |request| {
        if request.headers.contains("x-request-id") {
            // x_request_id is a uuid4
            let x_request_id = request.headers["x-request-id"];
            x_request_id.replace("-", "");
            print(`x-request-id: ${x_request_id}`);
           // x-trace-id is just a copy of x-request-id without dashes
           // so router can parse it properly
           // we then restore it to uuid format in the logs processor
           request.headers["x-trace-id"] = x_request_id;
       }
    };

    service.map_request(adapt_request_id);
}

Expected behavior

I expect that rhai-created header propagated to trace_id field in logs.

[BrynCooke]

Hi @kindermax, I'm afraid that what you are trying to do can't possibly work. Extracting the trace ID and constructing the root span is necessarily the first thing that should happen in the router. (There are some things that happen before but we are working to fix this).

I think we would accept a PR that simply strips out dashes in CustomTraceIdPropagator. Alternatively is this driven by use of AWS X-ray? If you can use a standard propagator and trace_id format it would be prefereable.

[kindermax]

Hi, unfortunately in my case uuid4 x-request-id is a company standard and generated by our nginx so I can not change its format. I think stripping dashes in CustomTraceIdPropagator would be enough in my case since I just need its value in my logs. Then I can do the reverse thing (adding dashes again) in my log processor. If you ok with it, I can try to make a pr

[BrynCooke]

That would be great. Make sure to add some sort of test. I think it's OK to strip dashes out as it's not as if we can use anything with dashes in.

[abernix]

@kindermax Do you think that the PR #5071 will resolve this satisfactorily?

[kindermax]

@abernix well, partially yes. If I put a log processor after router like this router | log_processor, then I will be able to restore original trace_id. Sure it wont work if the original trace_id were without dashes, because I will add dashes when I shouldn't. Alternatively, if there was a way just to add my header value to some field in logs (its a paid feature as far as i know) I would be able to just extract it in log processor.