Header added to request in rhai does not propagated into logs trace_id field about router HOT 5 CLOSED

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.

from router.

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.

from router.

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

from router.

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

from router.

@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.

from router.