search

ably / specification

The Ably features spec for client library SDKs.
Apache License 2.0
0 stars 4 forks source link

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

Open SimonWoolf opened 1 year ago

SimonWoolf commented 1 year ago

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[bot] commented 1 year ago

➤ Automation for Jira commented:

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

paddybyers commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Do we have more update on this @SimonWoolf ?

SimonWoolf commented 1 year ago

https://github.com/ably/specification/pull/150