clientOption for disabling resume?

[SimonWoolf]

Some people (e.g. this guy) want to avoid stale messages at all costs.

For the publishing side, we have queueMessages: false. But we don't currently have an easy way to avoid queueing on the subscribing side, i.e. connection state resumption - we just assume everyone wants it. Options currently are to catch disconnected event and either close() the connection explicitly, or call connectionManager.clearConnection(); (or equivalent). Both are pretty bad -- the former requires the user to then have to handle reconnection logic themselves, the latter is a non-public internal api.

We could solve this with a noResume client option that just clears connection state on disconnect with little effort, wdyt?

┆Issue is synchronized with this Jira Task by Unito

[paddybyers]

We could solve this with a noResume client option that just clears connection state on disconnect with little effort

I would support having this functionality.

The alternative of resume: false (ie with a true default) is perhaps nicer but doesn't fit well with languages whose booleans don't have an undefined value.

[mattheworiordan]

I am not a huge fan of setting this at a connection level I am afraid. I think that will not work in a lot of cases as it's plausible (we had this with a financial customer recently) that they have some channels for live pricing info and never care about historical pricing, and other channels were continuity is important.

Why set this at a connection level, when we are proposing to have channel attach flags. Related somewhat to ably/specification#80 in that in that issue too I argued we should stop forcing a developer to implement these blanket decisions at a connection level when they set up the connection.

[SimonWoolf]

Sure, doing it with channel attach flags would also work.

Maybe: a NO_BACKLOG flag that tells realtime to just never rewind() that channel (on attach, resume, or any other time), dropping continuity guarantees in favour of message liveness guarantees; channels attached with such a flag would get an ATTACHED without a channelSerial member to prevent the client from doing an untilAttach history request (as that wouldn't be meaningful with such a channel)

We really need to get on with deciding an attach flags api if we want to include it in 1.1 - #279 . Something to discuss in a couple weeks when we're all in London, maybe

[paddybyers]

Something to discuss in a couple weeks when we're all in London, maybe

We didn't get to do that. But I did talk about overall roadmap for client libraries with @funkyboy and this is one of the future things do implement across all libraries. I think we should resurrect the discussion on what the API would be.

[SimonWoolf]

We may want to consider again doing this as a clientOption on the connection level for now (even if we plan to eventually do it on a channel-by-channel basis with flags), just because it'd be so easy -- no realtime changes needed, no api change, only a single clientside option which'd be trivial to implement. Compared to a mechanism that uses channel attach flags, which has a bunch of prerequisites -- api design decisions, changes realtime-side to support new flags, and lots of clientside work to implement channel attach flags (which currently only ably-js comes close to doing).

[mattheworiordan]

We may want to consider again doing this as a clientOption on the connection level for now

I would advocate doing this, even if not a formal spec item i.e. perhaps an undocumented beta feature. As @SimonWoolf suggests, this should be trivial to implement.

For anyone else coming across this issue until then, our workaround for now is to, on the subscribe side, do something like

client.connection.on('disconnected', () => {
  client.connection.connectionManager.clearConnection();
});

with warnings that this was an internal api and may change in patch versions. This is also an ably-js specific solution.

[paddybyers]

This is also an ably-js specific solution.

We also need to say what the equivalent is in iOS and/or Android

[mattheworiordan]

See https://ably.atlassian.net/browse/CSS-144

[SimonWoolf]

This was implemented back in 2020 on the server side usable by a resumable: false transportParam, cf https://github.com/ably/realtime/pull/3008 . (The client still tries to resume, it'll just fail if the resume is not near-immediate (1s of leeway))