no way to set background context of rpc server

[stevvooe]

There doesn't seem to be a way to control the root context of the server. For example, it would be nice to have at least something like the following:

ctx := MySpecialContext()
s := NewServer(WithContext(ctx))

Such that the context passed to an implemented rpc method descends from the above:

func (mg *myGreeter) SayHello(context.Context, *HelloRequest) (*HelloReply, error) {}

Following from that, there doesn't seem to be a way to "prepare" a context using headers. One could imagine a per-request context preparation that incorporates header metadata (ie spans, auth, metrics, etc.) at the entire sever-level.

I may be missing API details in the documentation.

[dsymonds]

Contexts are request-scoped (see http://blog.golang.org/context). What would it mean for a server-wide context? If something is server-wide, it doesn't belong in a context.

[stevvooe]

@dsymonds The blog post outlines other uses as "cancelation signals, and deadlines across API boundaries to all the goroutines involved in handling a request". Not all of these boundaries may be exclusive to the request scope.

Imagine an API that could be used as part of a request-scoped server or client-side:

func GetStuff(ctx context.Context) (Stuff, error) { ... }

This method may use something in context but it doesn't care whether or not the context is request-scoped. Subsequently, we may configure the default resources used by GetStuff in a background context that then may be replaced at request time with something more specific to the context.

There may also be information setup in the background context that is service-wide but doesn't make sense to pass explicitly, such as loggers and tracing facilities.

[dsymonds]

Either you misread, or the blog post needs clarifying. That "API boundaries" reference does not suddenly let contexts escape from being request scoped. @Sajmani

[stevvooe]

@dsymonds That is a blog post I have read several times. I understand that the values are request scoped. There are cases where one wants to control the instantiation of the background context. Here is an example, written by you.

[dsymonds]

internal.BackgroundContext is not a good counter example. It is an edge case that is somewhat unfortunate and largely dictated by how App Engine works. It is not a model for how to otherwise write good Go APIs. If I were to redo everything in the entire Go App Engine ecosystem then that function may not even exist.

[stevvooe]

@dsymonds How would you accomplish the same task now?

[iamqizhao]

I have not seen a strong reason to have a server-scoped context so far. Close this now.

[stevvooe]

@iamqizhao @dsymonds Any insight implementing similar functionality to internal.BackgroundContext? A little more advice than "don't do that" would be helpful.

Allowing one to set the server context provides a mechanism to control the background context used in requests. The main reasoning behind requiring a server-scoped context is to avoid having different ways of transmitting contextual values depending on the use case.

[ilius]

I would say adding a context.SetBackground(ctx) feature would allow a process-scoped default context (not server-scoped or client-coped, since there is no boundary between server and client in microservice infra, most of our servers are also clients for other servers)

The same way that you can set http.DefaultClient or http.DefaultTransport in your own program (typically init func, or main), and that becomes the default for that process / program.

[menghanl]

@ilius You can append content to context using interceptor: https://godoc.org/google.golang.org/grpc#UnaryInterceptor