In the following sequence of events:
- status quo: connection connected; channel is attached
- client becomes disconnected for some period of time
- during this time, the user calls channel.presence.enter(). Since the channel is still in the attached state (as the client has been disconnected for less than two minutes), the enter is sent to the connection manager, which queues it.
- the client becomes connected again, but the resume failed. When the client discovers this, it initiates a reattach of all its attached channels. But the presence message, which was already queued, is sent as soon as the client became connected again.
The result is that the member is not entered - the enter fails, and the enter() callback is called with an errorinfo with message Unable to perform operation on channel: xxx (not currently attached) (90001; 404).
Strictly, this is fine: the enter fails and we call the callback with an error. No invariants are violated.
But still, there is room to handle this in a way that is more convenient for the user, with a tweak to the spec such that the enter is only sent once the channel is reattached. (needs some thought about what exactly to tweak -- we don't want to hold off on sending all queued messages until all channel reattachments are complete, so perhaps something along the lines of queueing the presence action in the channel rather than sending it to the conneciton unless/until we're both attached and connected. Which is a bit messy, breaks the abstraction that channel actions should depend only on the state of the channel. Needs thought.)
┆Issue is synchronized with this Jira Task by Unito
In the following sequence of events:
The result is that the member is not entered - the enter fails, and the enter() callback is called with an errorinfo with message
Unable to perform operation on channel: xxx (not currently attached)(90001; 404).Strictly, this is fine: the enter fails and we call the callback with an error. No invariants are violated.
But still, there is room to handle this in a way that is more convenient for the user, with a tweak to the spec such that the enter is only sent once the channel is reattached. (needs some thought about what exactly to tweak -- we don't want to hold off on sending all queued messages until all channel reattachments are complete, so perhaps something along the lines of queueing the presence action in the channel rather than sending it to the conneciton unless/until we're both attached and connected. Which is a bit messy, breaks the abstraction that channel actions should depend only on the state of the channel. Needs thought.)
┆Issue is synchronized with this Jira Task by Unito