Using Context to store TraceIDs

[William Kennedy]

I read this post by Jaana

https://docs.google.com/document/d/1GFHAksL5HQy1YacCFXMUdOTC4e21uoX-TbMzRXAtx_I/preview

I wanted to start a conversation about the Context value bag and TraceIDs. I am concerned with the idea of using the Context to pass TraceIDs into the API of packages that don't directly belong to a specific application.

I think this is a mistake on several fronts:

1) It kills readability because the TraceID is not part of the API. Information is being hidden.

2) It will lead to bugs that can't be found at compile time. Only at runtime can you identify is the TraceID was not provided.

3) It will force some API's to accept a Context with no clear understanding of why. What I mean, when I see Context I want to think cancellation.

I think it is a big mistake to hide anything in the Context for API's that exist outside the actual application. The use of the Context value bag is a policy decision that should not be found outside of the actual application itself. Middleware packages up to the handler could use the Context value bag, but then the handler needs to extract the TraceID and pass that into the business/service level API's. I would also say database connections show follow the same pattern.

I just wanted to start a larger conversation and get other thoughts and opinions.

[William Kennedy]

After reading this:

https://cloudplatform.googleblog.com/2017/04/distributed-tracing-for-Go.html

I can see how the Context is being used, through a separate API. Would it make sense to use a separate Context value for the "Trace" Context and use a separate Context value for the  "Cancellation" Context in the application independent package API's?

I am just starting to think about these things from an API and readability point of view. Just curious what others think.

[Daniel Theophanes]

Hi Bill,

Generally if you have a Trace ID, you are also doing something that involves multiple systems, processes, or routines. If that is the case, you also need a way to cancel your resource. Thus Trace ID is included with values in the context and not separated.

When Dave voiced his own preference to separate out Value from Cancelation, the response was, "it was considered, but the benefit and complication was deemed to not be worth it".

I understand what you are saying about hidden values and all, and how those aren't explicit. But I guess I don't personally care. This "not caring" can pay off where different applications have different per-request parameter needs, but want to leverage the same API for framework needs. 

That's my own 2 cents anyway. -Daniel

[William Kennedy]

I have come to the same conclusion. I just needed to write it down and listen to a few people talk about it. Thanks for the response.

I just want to be careful what we consider to be ok to be placed in the Context and what truly needs to be passed in as a separate argument.

--
You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/uaOtsp71MfM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jesper Louis Andersen]

In Erlang, we have a similar concept to the Context bag called the Process Dictionary. Its use is generally a nono because it breaks the rules for functional programming and allows you to have a shared space. We like to pass every argument explicitly in order to make it easier to read the code.

Yet, we've found again and again that there are situations where the value of the process dictionary outweighs functional programming. Among those are RNG state and process metadata, of which TraceIDs would be a prime example. Processes crashing list their PD as well.

A rule of thumb we often use is that the things you stuff in the PD must not be something which directly affects your programs behavior, though the RNG is a borderline case. I'd also be somewhat worried if the omission of a TraceID would ever affect a system. It ought to handle a nil return when calling span.FromContext() gracefully I think. It would be akin to most of the system I write: when a message does distributive transfer, you encode and marshal its meta-data on where relevant. The structure of the meta-data is given by convention, not by explicit notion.

In short: you have to balance convenience against correctness. I think Jaana's proposal manages to do just that, in particular by acknowledging this is likely to need future extension.

You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.