Support for gRPC request-scoped Spring beans (equivalent to net.devh's @Scope("grpcRequest"))

[lothar1998]

🧩 Feature Request

Background

When migrating from net.devh:grpc-server-spring-boot-starter to spring-grpc, one of the missing features is support for request-scoped Spring beans within a gRPC call.

In net.devh, this was provided via @Scope("grpcRequest") that activated a new scope for the duration of each gRPC call, allowing developers to inject @Scope("grpcRequest") beans that are created once per RPC and destroyed when the call completes.

A typical use case: injecting a per-request context object (e.g. authenticated principal, request metadata, tracing state) into multiple downstream components without passing it explicitly through method arguments.

Question

Is there a plan to support a similar mechanism in spring-grpc?

Possible approaches we can think of is a built-in @Scope("grpcRequest") / @RpcScope backed by a ServerInterceptor that manages the scope lifecycle per call.

If there are no plans, any guidance on the recommended approach for per-request state management in spring-grpc would be appreciated — ideally documented (e.g. in the reference docs or as a wiki entry) so that teams can implement their own solution without waiting for a potential future addition to the starter.

Context

spring-grpc version	1.0.2
Migrating from	net.devh:grpc-server-spring-boot-starter:3.1.0.RELEASE

[Khyojae]

I'd like to take a stab at this. A few design questions before I start:

1. For streaming RPCs, should scope last for the entire call or per-message?
2. New @RpcScope annotation vs reusing @scope("grpcRequest") string?
3. Should it integrate with reactor Context for the reactive variants?

[dsyer]

The implementation from net.devh could probably just be copied as is. I slightly prefer @GrpcRequestScope for a custom annotation.

Before we merge anything though, I'd like to know how useful this really is, given that the analogous @RequestScope doesn't get used much.