RESP3→RESP2 reconnect can replay SUBSCRIBE onto the interactive connection, permanently poisoning it

[sspeaks]

If a client initially connects via RESP3 protocol and then a reconnect is forced (say via a failover) and the reconnect HELLO fails for some reason (timeout due to connection flood, token expiry, etc), the proto is never parsed, and SE.R will send AUTH and CLIENT SETNAME/etc without ever setting proto — the tracer at the end of the handshake then sees no protocol was set and assigns RESP2. When it does so it creates a separation of the interactive/subscribe bridges, just as is needed for RESP2. However, any SUBSCRIBE (from  EnsureSubscriptions ) commands that were pushed onto the interactive bridge queue during the disconnect will still be sent to the interactive bridge, poisoning it against any subsequent GET/SET etc commands.

I imagine the fix is just making sure on such a reconnect downgrade, any queued subscription commands are moved to the subscription bridge?

[philon-msft]

...and HELLO will be especially slow on Azure Redis when using MS Entra ID auth. This issue comes from investigation of an Azure incident involving Entra auth.
It looks like when Azure Redis can't validate an Entra token within 10s it times out internally, causing the HELLO command to fail and triggering this issue.

[mgravell]

I will investigate; sounds like some kind of poisoned state i.e. we mark an endpoint as "we can do RESP3" which is then doomed if the HELLO 3 fails - hypothesis only, will look. There's also some wierdness here about how come AUTH worked and HELLO didn't... again, possibly just timing. Maybe it got flagged as timeout before the reply... or something weird.