Pub/sub: network lock error, and allows more than it should (Garnet 2.0.0 64 bit)

[mgravell]

Describe the bug

First, minor (ish): it looks like in RESP2 mode, even in pub/sub mode, the server is allowing arbitrary operations like set, get etc; this is invalid as it is not reliably possible to distinguish request/response responses from out-of-band message (which would be "push" types in RESP3). Redis responds with an error indicating that only a few operations are valid in that state - basically: [S|P][UB]SUBSCRIBE, PING and QUIT, noting that PING has different semantics in pub/sub mode. To repro:

subscribe foo

get bar <==== this should be a -ERR, and isn't (in RESP2 mode)

Second, this (equally invalidly) allows publish, which does weird things to the server:

subscribe foo

publish foo bar <==== this should also be a -ERR, and isn't (in RESP2 mode)

now switch to the server console:

03::45::44 fail: GarnetServer[0] An error occurred at RecvEventArg_Completed System.Threading.SynchronizationLockException: The calling thread does not hold the lock. at System.Threading.SpinLock.ExitSlowPath(Boolean useMemoryBarrier) at Garnet.common.GarnetTcpNetworkSender.ExitAndReturnResponseObject() in //libs/common/Networking/GarnetTcpNetworkSender.cs:line 150 at Garnet.server.RespServerSession.TryConsumeMessages(Byte* reqBuffer, Int32 bytesReceived) in //libs/server/Resp/RespServerSession.cs:line 500 at Garnet.networking.NetworkHandler2.TryProcessRequest() in /_/libs/common/Networking/NetworkHandler.cs:line 484 at Garnet.networking.NetworkHandler2.Process() in //libs/common/Networking/NetworkHandler.cs:line 340 at Garnet.networking.NetworkHandler2.OnNetworkReceiveWithoutTLS(Int32 bytesTransferred) in /_/libs/common/Networking/NetworkHandler.cs:line 274 at Garnet.common.TcpNetworkHandlerBase2.HandleReceiveWithoutTLS(Object sender, SocketAsyncEventArgs e) in //libs/common/Networking/TcpNetworkHandlerBase.cs:line 208

Steps to reproduce the bug

(above)

Expected behavior

No response

Screenshots

No response

Release version

No response

IDE

No response

OS version

No response

Additional context

No response

[mgravell]

Note, this should be allowed in RESP3, with out-of-band messages using push prefixes; however, adding hello 3 to the above, we still get the socket lock error.