PING responses are not decoded properly if Pub/Sub connection is subscribed #579
Labels
type: bug
A general bug
Milestone
Comments
|
In a subscription state, it's not distinguishable (from an ordering perspective) whether a response is related to a sent command or it's a Pub/Sub response. Making that distinction would require response inspection and pre-processing. For now, we deny non-pubsub commands once the connection has entered Pub/Sub state. |
mp911de
added a commit
that referenced
this issue
Oct 6, 2017
Pub/Sub connections that are subscribed to at least channel/pattern allow only subscription commands to be executed and reject execution of commands other than SUBSCRIBE, PSUBSCRIBE, UNSUBSCRIBE, PUNSUBSCRIBE and QUIT. Response correlation cannot be guaranteed because Redis can publish a message first and then process the actual command which would parse the message as command response and treat the actual command response as pub/sub message. A deep response inspection could help to identify non-pub/sub message responses but it's no guarantee.
mp911de
added a commit
that referenced
this issue
Oct 6, 2017
Pub/Sub connections that are subscribed to at least channel/pattern allow only subscription commands to be executed and reject execution of commands other than SUBSCRIBE, PSUBSCRIBE, UNSUBSCRIBE, PUNSUBSCRIBE and QUIT. Response correlation cannot be guaranteed because Redis can publish a message first and then process the actual command which would parse the message as command response and treat the actual command response as pub/sub message. A deep response inspection could help to identify non-pub/sub message responses but it's no guarantee.
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See #576 (comment).
The text was updated successfully, but these errors were encountered: