Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Use @MessageMapping method signature to constrain RSocket interaction model #23999
Currently, our RSocket support is mapping
Context of the issue
The case of "fire and forget" requests, where the requester sends a request and does not expect any response, can be interesting here in the context of our flexible signature support and the current mapping process.
While looking at our RSocket support with @snicoll, we considered a Controller handler that returns a response stream:
If a requester calls this handler with a fire and forget interaction type:
Then we're getting the following exception on the server side:
In this particular case (and in general), we can find pairs of handler definitions / rsocket interactions that mismatch in our mapping infrastructure. For example, a request can be mapped to a handler, the handler is executed but the returned subscriber is not subscribed to.
After chatting with @rstoyanchev, we thought that we should enforce a few design choices in our implementation.
Refining message mappings with handler return types
First, when mapping requests on handlers, returning more elements than expected should not be allowed, but returning less than expected should be permitted.
Not allowing ambiguous mappings
Even in the light of this (restricting message mapping depending on the handler return type), we should not allow multiple handlers with the same route. If this happens, this will be treated as an error since the mapping is ambiguous.
The way this came out in the end is that
See the changes in the reference docs for more details.
Related to spring-projects/spring-framework#23999 * Since Spring Integration inbound endpoints are generic in their method signature we can't rely on a new `EMPTY_CONDITION` because it turns on configuration merge into just `FrameType.REQUEST_FNF` & `FrameType.REQUEST_RESPONSE`. So, use `FrameType.REQUEST_FNF`, `FrameType.REQUEST_RESPONSE`, `FrameType.REQUEST_STREAM` & `FrameType.REQUEST_CHANNEL` explicitly to cover all the valid request-response models for SI endpoints * Rework `RSocketOutboundGatewayIntegrationTests` according new logic. Plus refactor to earlier subscription into `FluxMessageChannel` to avoid potential race conditions