Make queueMessages=false suppress the behaviour of resending pending messages on a new transport?

[SimonWoolf]

RTN19a the requirement (after a transport disconnection the client lib must resend any pending (awaiting ack/nack) messages on the new transport) does not currently make an exception for when queueMessages=false.

Arguably it should, because the intention of queueMessages=false is 'never send stale messages', and with this behaviour, we might sometimes be doing that

So, proposal: add RTN19a3 (or RTN7d? it'd fit in either place) to clarify that when queueMessages=false, immediately on transport disconnection, the all messages awaiting ack/nack will have their callback called with an appropriate error, and should not be resent on any new transport

cc @paddybyers

[sync-by-unito]

➤ Automation for Jira commented:

The link to the corresponding Jira issue is https://ably.atlassian.net/browse/SDK-3471

[paddybyers]

If we're connected, in what situation will we be queueing messages? The only case I can think of would be presence messages that are waiting pending attachment.

What about the case of a deploy where there is a momentary disconnection - don't we want to try to make that fully transparent? Is there an argument for saying that messages are nacked if the first immediate reconnect attempt fails?

[SimonWoolf]

If we're connected, in what situation will we be queueing messages? The only case I can think of would be presence messages that are waiting pending attachment.

to be clear - the case I'm proposing to tweak here is messages for which a publish has been attempted and where you're waiting to hear an ack/nack

Internal context / customer support request: https://ably-real-time.slack.com/archives/C0174D4AP4P/p1679402280230259

What about the case of a deploy where there is a momentary disconnection - don't we want to try to make that fully transparent? Is there an argument for saying that messages are nacked if the first immediate reconnect attempt fails?

Yeah, that is a downside. Possible best of both worlds might be to clear on disconnected state, since the immediate reconnect goes straight from connected to connecting

[sacOO7]

Do we have more update on this @SimonWoolf ?

[SimonWoolf]

#150