HTTP request with special X-Request-Id can NOT be traced in Istio

curl a service with following two ways:

curl http://svc:20888/path  -H 'X-Request-Id: 8cda17a5-eb41-4ced-9843-acc826f95c8c'
curl http://svc:20888/path -H 'X-Request-Id: 27290d28d5c38da315a78399d71fc20b'

The former request with a valid uuid as x-request-id can be traced successfully,
while the latter with a invalid uuid does not be traced, thex-request-id is generated by some old app.

My question is why the formation of x-request-id affects the tracing.

The detail pls refer the issue

Envoy conveys information about the sampling mode in the x-request-id, see

The code is here.

Thanks for the code reference. Still not understand why user’s original x_request_id be checked and modified here.

Not sure of the history - probably best to raise the question on the envoy repo. In practice, once the sampling decision has been made, the decision is carried using the tracer specific context propagation format (e.g. b3) - so encoding it in the x-request-id shouldn’t be necessary.

Yes, x-b3-sampled is set in envoy and app propagate it across one request, which decide weather the trace should be collected.