See also #19643. /cc @Sajmani @zombiezen @bcmills

Some values in the Context may have finite lifetimes after which they can no longer be used. (For example, when the End method of an OpenCensus Spans is called, it is flushed to the Exporters, and future annotations to the span will be lost.)

In such cases, you need something more than just to carry over the values: you need to filter out values that can no longer be used, or perhaps extend their lifetimes.

That sort of use-case doesn't seem to be addressed in this proposal.

Some values in the Context may have finite lifetimes after which they can no longer be used. (For example, when the End method of an OpenCensus Spans is called, it is flushed to the Exporters, and future annotations to the span will be lost.)

@bcmills can you elaborate on the given example, for those who are not familiar with the code - as it seems to me, if there is an explicit call to End, you can override values with nil value. In the case of spans, I think that we will want to record calls, even after the handler was finished? So we could see related propagation of the request even in asynchronous task.

And generally, what sort of cases need filtering out values from the context?

it seems to me, if there is an explicit call to End, you can override values with nil value.

Overrides of context values are generally scoped to subtrees of the function call tree: context.WithValue produces an immutable entry in the tree.

In the case of spans, I think that we will want to record calls, even after the handler was finished?

Right, that's the problem: when End is called, the Span is flushed out to the log and nothing more can be recorded for it.

I'm sorry, I don't understand how spans are bad example here:

1. In the same manner that you you don't close channel twice, you should not sent spans twice - you'll get an error (for example, a span manager pointed by the context could hold a state).
2. As far as I can understand the same issue could arouse In the current design of spans - I can send them several times manually.
3. I guess that the common case is to have a middleware that will handle the spans, and it will remain unharmed with this change.

For long running tasks that were created from HTTP handlers - I think it is bad practice to create a new context for them, and it is important for them to know the context that they came from. The examples I gave demonstrate the need, and they don't have a solution currently in the standard library.

I guess that the common case is to have a middleware that will handle the spans, and it will remain unharmed with this change.

The middleware is exactly the point: at some point, that middleware needs to know when to flush the span, and at the moment the only reasonable signal it gets is “the next handler down the chain has returned”.

I guess that the common case is to have a middleware that will handle the spans, and it will remain unharmed with this change.

The middleware is exactly the point: at some point, that middleware needs to know when to flush the span, and at the moment the only reasonable signal it gets is “the next handler down the chain has returned”.

Maybe asynchronous task trace should not be the same as the handler itself trace. Maybe if you want to send spans from asynchronous task, you should create a new trace and send it when you are done?

Maybe if you want to send spans from asynchronous task, you should create a new trace and send it when you are done?

Yes, that's exactly my point: if the trace may be stored and accessed in the Values of a Context, then it is inappropriate to propagate those values to an asynchronous task.

This need can be satisfied outside the standard library, as you have. (https://github.com/posener/ctxutil/blob/master/values.go)

There are various things you might want to do to mix parts of two contexts. It's not clear which one is "right" if we're going to have a blessed mixer. Better for users who need a specific kind of mix to implement it themselves. This is why context.Context is an interface.

This is why context.Context is an interface.

Note that any context.Context implementation outside the standard library imposes an extra goroutine every time context.WithCancel or context.WithDeadline is called on it.

If we're going to press for folks to address these sorts of issues outside the standard library, we should probably make the standard library play more nicely with external implementations.