Current realtime presence sync behaviour after a resume contradicts RTP3

[SimonWoolf]

RTP3:

If a SYNC operation is underway but not yet complete, and the transport is disconnected unexpectedly, then if the connection is resumed successfully, it is the responsibility of the client library to complete the SYNC operation. The client library requests a SYNC resume by sending a SYNC ProtocolMessage with the channelSerial set to the same as the channelSerial of the most recently received SYNC.

What happens now is that after a resume, the client gets an ATTACHED and then a full SYNC, automatically and unconditionally. I think this was one of the things Paddy changed with the 1.0 spec, as part of the avoiding-clients-getting-channel-state-out-of-sync changes.

Given this, RTP3 no longer makes any sense. I don't think there's now any situation where the client would need or want to resume a sync -- if they miss part of a sync, that implies a transport interruption, so the action is to disconnect and do a resume, which will do a full sync of everything.

So any reason not to just remove RTP3? @mattheworiordan / @paddybyers ?

┆Issue is synchronized with this Jira Task by Unito

[mattheworiordan]

if they miss part of a sync, that implies a transport interruption, so the action is to disconnect and do a resume, which will do a full sync of everything.

Well that seems awfully inefficient given it seems perfectly valid to continue a SYNC operation if possible.

Before removing this, I'd like to understand why a SYNC resume is not possible

[paddybyers]

Should we resolve this in the 1.1 spec?

I think resuming the sync, or being given a new sync, are both valid behaviours and although realtime always starts a new sync, libraries should support both. So perhaps the requirement should be that the client library resumes an interrupted in-progress sync if realtime does not initiate a new sync in the attached response.

[mattheworiordan]

So perhaps the requirement should be that the client library resumes an interrupted in-progress sync if realtime does not initiate a new sync in the attached response.

Just to clarify my understanding, are we saying that every time we resume we send an ATTACHED message for every channel now, and initiate a full SYNC?

[paddybyers]

Just to clarify my understanding, are we saying that every time we resume we send an ATTACHED message for every channel now, and initiate a full SYNC?

ATTACHED - yes; full SYNC for those channels that have some presence.

[SimonWoolf]

although realtime always starts a new sync, libraries should support both. So perhaps the requirement should be that the client library resumes an interrupted in-progress sync if realtime does not initiate a new sync in the attached response.

RTP1 in the 1.0 spec:

"(RTP1) When a channel ATTACHED ProtocolMessage is received, the ProtocolMessage may contain a HAS_PRESENCE bit flag indicating that there are currently members present on the channel, see TR3 . If the flag is 1, the server will shortly perform a SYNC operation as described in RTP18 . If that flag is 0 or there is no flags field, the presence map should be considered in sync immediately with no members present on the channel"

I.e. realtime guarantees that:

• if there are present members, HAS_PRESENCE will be set
• if HAS_PRESENCE is set, a SYNC will shortly follow

Together, these make it a protocol violation for realtime to send an ATTACHED on a channel with presence members without also doing a full sync. (To put it another way, there's no separate WILL_DO_A_SYNC flag, only HAS_PRESENCE). Seems a bit pointless for client libs to have to support behaviour (resuming a sync in the event realtime fails to do one) that would be a protocol violation if it ever actually happened.

[sync-by-unito]

➤ Automation for Jira commented:

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