LoadBalancedRsocketMono generates cancel signal along with complete for interceptors

[ilterpehlivan]

I am trying to test interceptors with LoadBalancedRsocket client and while running a sample with requestReply then receiving Cancel signal type right after Complete inside the interceptor

Expected Behavior

Only Complete should come

Actual Behavior

Cancel + Complete both comes

Logs:

06 Jun 2020 03:37:30 DEBUG [main] o.e.Main - Client sends requestN(9223372036854775807)
06 Jun 2020 03:37:30  INFO [main] o.e.TestRsocket - iniside the interceptor requestresponse
06 Jun 2020 03:37:30 DEBUG [reactor-tcp-nio-3] i.r.FrameLogger - receiving -> 
Frame => Stream ID: 0 Type: SETUP Flags: 0b0 Length: 56
Data:

06 Jun 2020 03:37:30 DEBUG [reactor-tcp-nio-2] i.r.FrameLogger - sending -> 
Frame => Stream ID: 1 Type: REQUEST_RESPONSE Flags: 0b0 Length: 18
Data:
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 48 65 6c 6c 6f 20 43 6c 69 65 6e 74             |Hello Client    |
+--------+-------------------------------------------------+----------------+
06 Jun 2020 03:37:30 DEBUG [reactor-tcp-nio-3] i.r.FrameLogger - receiving -> 
Frame => Stream ID: 1 Type: REQUEST_RESPONSE Flags: 0b0 Length: 18
Data:
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 48 65 6c 6c 6f 20 43 6c 69 65 6e 74             |Hello Client    |
+--------+-------------------------------------------------+----------------+
06 Jun 2020 03:37:30  INFO [reactor-tcp-nio-3] o.e.TestRsocket - iniside the interceptor requestresponse
06 Jun 2020 03:37:30 DEBUG [reactor-tcp-nio-3] i.r.FrameLogger - sending -> 
Frame => Stream ID: 1 Type: NEXT_COMPLETE Flags: 0b1100000 Length: 18
Data:
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 48 65 6c 6c 6f 20 73 65 72 76 65 72             |Hello server    |
+--------+-------------------------------------------------+----------------+
06 Jun 2020 03:37:30  INFO [reactor-tcp-nio-3] o.e.TestRsocket - doFinally: signal onComplete
06 Jun 2020 03:37:30 DEBUG [reactor-tcp-nio-2] i.r.FrameLogger - receiving -> 
Frame => Stream ID: 1 Type: NEXT_COMPLETE Flags: 0b1100000 Length: 18
Data:
         +-------------------------------------------------+
         |  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f |
+--------+-------------------------------------------------+----------------+
|00000000| 48 65 6c 6c 6f 20 73 65 72 76 65 72             |Hello server    |
+--------+-------------------------------------------------+----------------+
06 Jun 2020 03:37:30  INFO [reactor-tcp-nio-2] o.e.TestRsocket - it is cancelled
06 Jun 2020 03:37:30 DEBUG [reactor-tcp-nio-2] i.r.FrameLogger - sending -> 
Frame => Stream ID: 1 Type: CANCEL Flags: 0b0 Length: 6
Data:

06 Jun 2020 03:37:30  INFO [reactor-tcp-nio-2] o.e.TestRsocket - doFinally: signal cancel
06 Jun 2020 03:37:30  INFO [reactor-tcp-nio-2] o.e.Main - Hello server
06 Jun 2020 03:37:30  INFO [main] o.e.Main - 

Steps to Reproduce

Example app
https://gist.github.com/ilterpehlivan/92e1121998e3678e74ad0556fb9018ff

Your Environment

• RSocket version(s) used: 1.0.0
• Other relevant libraries versions (eg. netty, ...):
• Platform (eg. JVM version (javar -version) or Node version (node --version)): 1.8
• OS and version (eg uname -a):OsX

[OlegDokuka]

In 1.0.x, this was a result of indirect MonoNext usage in LoadbalancedRsocketMono which comes with Mono.from(Publisher) in the internals. This also results in the cancellation frame, being sent from the client-side to a server, which is unwanted behavior.

This is fixed for 1.1.0 including improvements in Loadbalancer API (starting from 1.1.0 you do not have to do put retry() anymore to wait for first available connection as well as countDownLatch is unnecessary).

However, you will still observe a cancellation on the server-side only (no frame anymore) which will be fixed in M2. (please follow #916)