... where {vrsn} is resolved to 2.0 as coded in reservation-service-client's ReservationServiceClient like so:
public Mono<ReservationConfirmation> createReservation(CreateReservationRequest request) {
String version = "2.0";
return rsocketRequester.route("create.reservation.{vrsn}", version)
.data(request)
.retrieveMono(ReservationConfirmation.class)
.log();
}
Thus, the client should be forwarded to a reservation-service instance of version 2.0-RELEASE (which is not available). However, that is not the case, and client is getting forwarded to a service instance of version 1.0-RELEASE.
When the client sends the request via the gateway to the service, you can see output in the gateway logs, that the forwarding metadata is properly available and {vrsn} was resolved properly as well, yet the gateway simply forwards to the reservation-service instance of version 1.0-RELEASE although the client routing metadata states otherwise.
Expected behaviour in this case (imo) would be to respond with max backpressure from the gateway since the service is not (yet) available.
To reproduce:
start service-gateway
start reservation-service
start reservation-service-client
send a POST request to http://localhost:9999/reservation/create/ReservationName (Web endpoint of client that will send the RSocket request)
I am using ... Spring Boot: 2.2.0.RELEASE Spring Cloud: Hoxton.BUILD-SNAPSHOT Spring Cloud RSocket: 0.2.0.BUILD-SNAPSHOT Sample project: here
In my setup
reservation-service-client
communicates withreservation-service
via RSocket and theservice-gateway
.reservation-service
registers with the following route metadata tags (seereservation-service/src/main/resources/application.yml
):reservation-service-client
declares forwarding information like that(seereservation-service-client/src/main/resources/application.yml
):... where
{vrsn}
is resolved to2.0
as coded inreservation-service-client
'sReservationServiceClient
like so:Thus, the client should be forwarded to a
reservation-service
instance of version2.0-RELEASE
(which is not available). However, that is not the case, and client is getting forwarded to a service instance of version1.0-RELEASE
.When the client sends the request via the gateway to the service, you can see output in the gateway logs, that the forwarding metadata is properly available and {vrsn} was resolved properly as well, yet the gateway simply forwards to the
reservation-service
instance of version1.0-RELEASE
although the client routing metadata states otherwise.Expected behaviour in this case (imo) would be to respond with max backpressure from the gateway since the service is not (yet) available.
To reproduce:
service-gateway
reservation-service
reservation-service-client
http://localhost:9999/reservation/create/ReservationName
(Web endpoint of client that will send the RSocket request)