Description of the problem including expected versus actual behavior. Please include screenshots (if relevant):
Is there a way when a third party http client (apollo graphql that itself create a transaction on APM) consume on of my controller to propagate automatically the transaction it has already spawn on APM?
I already use this successfully to propagate my transaction across many events pushed/pulled against a broker, but should I do the same into my controller where my transaction is automatically spawn, from let's say the transaction id that the client may put into the header then override the implicit transaction with a new one using this transactionId ?
Could you confirm that the client http has to supply both http.request.headers.Elastic-Apm-Traceparent and http.request.headers.Traceparent in the headers (with the same value ?) to make the implicit transaction spawn in the .net agent using it ?
correct - the headers you identified are responsible for propagating the distributed trace context via HTTP.
The Elastic agents support the official W3C Trace Context specification, which means that traceparent is already sufficient.
For backward compatibility, the elastic-apm-traceparent is also still in use.
We face the case where the client (Apollo GraphQL) provides an id in ( http.request.headers.Traceparent) that doesn't exist in APM, so our .net transaction initiate a transaction with it (as expected) but obviously it's not linked to any client calling transaction.
Is it possible if the possible behavior if the APM client (nodejs) is sampled ?
By the way, I think this theory is wrong because the initiated transaction by Apollo exists, it simply not supplied in http.request.headers.Traceparent, but it is in http.request.headers.Elastic-Apm-Traceparent... instead.
So to be clear, the transaction initiated by the client (Apollo GraphQL) is on APM with a trace.id f7d58d08e640843d027dc597a3ba8a41, but the supplied headers to the .net application are not equals: one is the trace.id of the client, and the second one is a new id unknow on APM.
Here are the supplied ids : http.request.headers.Elastic-Apm-Traceparent = 00-f7d58d08e640843d027dc597a3ba8a41-eb4a28da6f23a747-01
and http.request.headers.Traceparent = 00-21caaf095d7a73309be4bbe6cd17262e-44185e788ca0c232-01
The first one is basically the trace.id of the client, the second one is the one used by the .net application receiving the http call to initiate it's own transaction (not correlated to the client thus).