[reactor-grpc][question] grpc context in subscriber context

[Tiller]

Hi,

I was wondering if the following could be a good addition: In ServerCalls, to add the Context.current() into the subscriber context. This would allow to have the grpc context available at anytime within the handling functions without worrying if the thread was switched or not.

The very best solution would be to put all values of the grpc context into the subscriber context, but it doesn't seem possible to list the content of a grpc context.

Note: implementation would be as simple as:

    public static <TRequest, TResponse> void oneToOne(...) {
        //...
        Mono<TResponse> rxResponse = Preconditions.checkNotNull(delegate.apply(rxRequest));
        rxResponse.subscriberContext(ctx -> ctx.put(Context.class, Context.currentContext()).subscribe(...);
    }

[rmichela]

How would that work if a server subscriber then called another gRPC service? The gRPC context would then be broken unless you knew to explicitly set the client request context.

[Tiller]

I must say that I only thought about the server's side context, and not about the server then playing the role of a client. If I'm not mistaken (and I might be, I only started with week with grpc & reactive-grpc) the ServerCalls method is only used when handling client requests on the server side. So even if the server were to call other services, they would not override the context and the server context would still be in the subscriber context.

The issue you might have is that after a call to another service you might expect the context in the subscriber context to be the client's and not the server's. But this could be "solved" pretty easily I think by distinguishing the server context from the client contexts. And doing for example something like:

rxResponse.subscriberContext(ctx -> ctx.put("serverContext", Context.currentContext()).subscribe(...);

Also, I haven't looked at the client implementation at all, but from what I saw in the documentation, we should not "break the chain" when using it, implying no flatMap and all? So as long as we don't "break the chain" I think the client could have its own context put in the context without interfering with the server's. (reminder, the subscriber context is propagated upstream, not downstream)