-
Notifications
You must be signed in to change notification settings - Fork 4.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no way to set background context of rpc server #172
Comments
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. |
@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:
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 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. |
Either you misread, or the blog post needs clarifying. That "API boundaries" reference does not suddenly let contexts escape from being request scoped. @Sajmani |
@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 How would you accomplish the same task now? |
I have not seen a strong reason to have a server-scoped context so far. Close this now. |
@iamqizhao @dsymonds Any insight implementing similar functionality to 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. |
I would say adding a The same way that you can set |
@ilius You can append content to context using interceptor: https://godoc.org/google.golang.org/grpc#UnaryInterceptor |
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:
Such that the
context
passed to an implemented rpc method descends from the above: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.
The text was updated successfully, but these errors were encountered: