Propagate trace info in X-Cloud-Trace-Context header

[meltsufin]

Currently, we ingest X-B3-* and GCP's X-Cloud-Trace-Context with X-B3-* given higher priority, but we only propagate X-B3-* headers. The proposal is to also propagate the X-Cloud-Trace-Context for full symmetry and full compatibility with GCP.

Follow-up to #96 and #97.

cc/ @elefeint

[codefromthecrypt]

while this will add overhead as long as the feature itself is optional and only added when in gcp (something out of scope for this repo) sounds fine to me. if someone complains we can consider parameterizing. cc @anuraaga

[anuraaga]

Actually I didn't know there was even a propagation module here - will start using it :D And yeah having the extra header is not a big deal for me.

[elefeint]

Perhaps we could propagate X-Cloud-Trace-Context in this project, but only if it were present upon ingestion?

In the scenario below, the non-GCP-app would then be able to propagate the header even though it itself does not run on GCP:
GCP-app --> non-GCP-app --> another-GCP-app

[codefromthecrypt]

that is possible either via a flag or request specific. if request specific it would mean adding an "extra" object to the context which indicates this. that part isnt well documented I admit. let me know if others want this.

…

On Thu, 11 Oct 2018, 20:48 elefeint, ***@***.***> wrote: Perhaps we could propagate X-Cloud-Trace-Context in this project, but only if it were present upon ingestion? In the scenario below, the non-GCP-app would then be able to propagate the header even though it itself does not run on GCP: GCP-app --> non-GCP-app --> another-GCP-app — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#98 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAD61xl_U2hjJOue-eOn1437kosEWwOKks5ujz4lgaJpZM4XVV8t> .