Spec for queued messages following a reconnect about docs HOT 5 CLOSED

Client reconnects, but is unable to resume, so detaches all channels

Why unable to resume?

This is the current behaviour:

Either:
a) the connection fails - no issue then
b) the resume on the given channel fails with an error the system deems to be fatal: so the channel enters the failed state, none of the locally queued messages are published and no new messages are received;
c) the resume on the given channel fails with a non-fatal error, meaning that the channel is reattached but with some discontinuity in the messages; this means that the resume returns as many historical messages on the channel as are available, which might or might not include the other client's 3 messages, and an error is returned indicating the problem. The 5 new queued messages are sent once attached.

When we in future support implicit attach on publish and multiple attach modes (publish, publish+subscribe etc) I don't really see that changing, except that there is a variation of case (b) where the fatal problem might apply to publish only, or to subscribe only, in which case the attach mode could be downgraded without failing the channel.

from docs.

@paddybyers to be clear, I raised this issue not because I don't agree with your suggested approach above, but because we have not been specific enough in our spec, see http://docs.ably.io/client-lib-development-guide/features/#RTN15c3. There is NO mention whatsoever of queued messages and how to handle them, so every client library developer will likely implement this differently because we have been unspecific. I am happy with a and b, still unhappy with c but will go ahead and leave that in until we resolve this issue in 0.9.

When we in future support implicit attach on publish and multiple attach modes (publish, publish+subscribe etc) I don't really see that changing, except that there is a variation of case (b) where the fatal problem might apply to publish only, or to subscribe only, in which case the attach mode could be downgraded without failing the channel.

I would disagree in fact, I think if a channel that was open becomes detached, then it's just easier to simply fail those messages so that the developer can decide what recovery activity they would like to take.

Given describing this in the spec is a very minor change, and not a change of functionality, but clarifying expected functionality, I will ago ahead and do a PR later.

from docs.

I would disagree in fact, I think if a channel that was open becomes detached, then it's just easier to simply fail those messages so that the developer can decide what recovery activity they would like to take.

I do agree that varying the mode of the channel attachment will be an unnecessary complexity, and if we can no longer honour the requested mode then it detaches completely.

from docs.

Given describing this in the spec is a very minor change, and not a change of functionality, but clarifying expected functionality, I will ago ahead and do a PR later.

Sure

from docs.

This is resolved

from docs.