Create first draft of the use cases document #425
Conversation
|
|
||
| This document is a loose, unordered and ongoing collection. | ||
|
|
||
| ## Usecase 1: Report the proposed parent ID back to the caller |
There was a problem hiding this comment.
While it is good you describe use cases for such things I believe those should be self described. For example, why some systems can't create a trace ID and span ID, why the caller would need a parent ID? Does the parent ID is enough info without the trace ID?
Use case as it is feels like describing the what and not the why.
There was a problem hiding this comment.
This topic has been well discussed and is niche at best. It doesn't deserve the "usecase 1" if anything "honorable mention"
Returning trace IDs is far more frequent for putting traces together without this odd notion of "proposed parent ID". Maybe you can put more routine things here by looking at the issues leading up to this or asking users.
For example, this issue from over 4 years ago catalogs some ideas with real people who were interested openzipkin/b3-propagation#4
|
#406 was intending to remove exactly this |
| This document is a loose, unordered and ongoing collection. | ||
|
|
||
| ## Usecase 1: Report the proposed parent ID back to the caller | ||
|
|
There was a problem hiding this comment.
Here is another use case - Currently some of the Azure Control Plane APIs return Correlation Id as part of the response header which can then be used by the customer on reporting an issue or contacting us. We would like to have teams transition to using the standard W3C trace content and returning this as standard response header. Having the trace context in the form of the traceresponse header would make this easy for customers and enable us to pinpoint issues.
This is the first shot at a document that collects use-cases for response headers.