Move resumability decisions from the client to the server#488
Open
SimonWoolf wants to merge 1 commit into
Open
Move resumability decisions from the client to the server#488SimonWoolf wants to merge 1 commit into
SimonWoolf wants to merge 1 commit into
Conversation
lmars
approved these changes
Jun 15, 2026
lmars
left a comment
lmars
left a comment
Member
There was a problem hiding this comment.
Some wording related comments, but otherwise LGTM.
| | DETACHING || A detach has been initiated on an `ATTACHED` channel by sending a request to Ably. This is a transient state, followed either by a transition to `DETACHED` or `FAILED`. | | ||
| | DETACHED || The channel, having previously been `ATTACHED`, has been detached by the user. | | ||
| | SUSPENDED || The channel, having previously been `ATTACHED`, has lost continuity, usually due to the client being disconnected from Ably for longer than two minutes. It will automatically attempt to reattach as soon as connectivity is restored. | | ||
| | SUSPENDED || The channel, having previously been `ATTACHED`, is waiting until the client to reconnect to Ably after an extended period of disconnection. It will automatically reattach once connectivity is restored. Message continuity may have been lost, but the authoritative source for this is the [`resumed`]{@link ChannelStateChange#resumed}) flag on the subsequent `attached` state change. | |
Member
There was a problem hiding this comment.
Suggested change
| | SUSPENDED || The channel, having previously been `ATTACHED`, is waiting until the client to reconnect to Ably after an extended period of disconnection. It will automatically reattach once connectivity is restored. Message continuity may have been lost, but the authoritative source for this is the [`resumed`]{@link ChannelStateChange#resumed}) flag on the subsequent `attached` state change. | | |
| | SUSPENDED || The channel, having previously been `ATTACHED`, is waiting for the client to reconnect to Ably after an extended period of disconnection. It will automatically reattach once connectivity is restored. Message continuity may have been lost, but the authoritative source for this is the [`resumed`]{@link ChannelStateChange#resumed}) flag on the subsequent `attached` state change. | |
| | CONNECTED || A connection exists and is active. | | ||
| | DISCONNECTED || A temporary failure condition. No current connection exists because there is no network connectivity or no host is available. The disconnected state is entered if an established connection is dropped, or if a connection attempt was unsuccessful. In the disconnected state the library will periodically attempt to open a new connection (approximately every 15 seconds), anticipating that the connection will be re-established soon and thus connection and channel continuity will be possible. In this state, developers can continue to publish messages as they are automatically placed in a local queue, to be sent as soon as a connection is reestablished. Messages published by other clients while this client is disconnected will be delivered to it upon reconnection, so long as the connection was resumed within 2 minutes. After 2 minutes have elapsed, recovery is no longer possible and the connection will move to the `SUSPENDED` state. | | ||
| | SUSPENDED || A long term failure condition. No current connection exists because there is no network connectivity or no host is available. The suspended state is entered after a failed connection attempt if there has then been no connection for a period of two minutes. In the suspended state, the library will periodically attempt to open a new connection every 30 seconds. Developers are unable to publish messages in this state. A new connection attempt can also be triggered by an explicit call to [`connect()`]{@link Connection#connect}. Once the connection has been re-established, channels will be automatically re-attached. The client has been disconnected for too long for them to resume from where they left off, so if it wants to catch up on messages published by other clients while it was disconnected, it needs to use the [History API](https://ably.com/docs/realtime/history). | | ||
| | DISCONNECTED || A temporary failure condition. The client has been disconnect from Ably, usually due to network connectivity. It will periodically attempt to open a new connection (about every 15 seconds). In this state, you can continue to publish messages, which will be queued to be sent once a connection is reestablished. Messages published by other clients while this client is disconnected will be delivered to it upon reconnection if the server is able to preserve continuity. | |
Member
There was a problem hiding this comment.
Suggested change
| | DISCONNECTED || A temporary failure condition. The client has been disconnect from Ably, usually due to network connectivity. It will periodically attempt to open a new connection (about every 15 seconds). In this state, you can continue to publish messages, which will be queued to be sent once a connection is reestablished. Messages published by other clients while this client is disconnected will be delivered to it upon reconnection if the server is able to preserve continuity. | | |
| | DISCONNECTED || A temporary failure condition. The client has been disconnected from Ably, usually due to network connectivity. It will periodically attempt to open a new connection (about every 15 seconds). In this state, you can continue to publish messages, which will be queued to be sent once a connection is reestablished. Messages published by other clients while this client is disconnected will be delivered to it upon reconnection if the server is able to preserve continuity. | |
| | DISCONNECTED || A temporary failure condition. No current connection exists because there is no network connectivity or no host is available. The disconnected state is entered if an established connection is dropped, or if a connection attempt was unsuccessful. In the disconnected state the library will periodically attempt to open a new connection (approximately every 15 seconds), anticipating that the connection will be re-established soon and thus connection and channel continuity will be possible. In this state, developers can continue to publish messages as they are automatically placed in a local queue, to be sent as soon as a connection is reestablished. Messages published by other clients while this client is disconnected will be delivered to it upon reconnection, so long as the connection was resumed within 2 minutes. After 2 minutes have elapsed, recovery is no longer possible and the connection will move to the `SUSPENDED` state. | | ||
| | SUSPENDED || A long term failure condition. No current connection exists because there is no network connectivity or no host is available. The suspended state is entered after a failed connection attempt if there has then been no connection for a period of two minutes. In the suspended state, the library will periodically attempt to open a new connection every 30 seconds. Developers are unable to publish messages in this state. A new connection attempt can also be triggered by an explicit call to [`connect()`]{@link Connection#connect}. Once the connection has been re-established, channels will be automatically re-attached. The client has been disconnected for too long for them to resume from where they left off, so if it wants to catch up on messages published by other clients while it was disconnected, it needs to use the [History API](https://ably.com/docs/realtime/history). | | ||
| | DISCONNECTED || A temporary failure condition. The client has been disconnect from Ably, usually due to network connectivity. It will periodically attempt to open a new connection (about every 15 seconds). In this state, you can continue to publish messages, which will be queued to be sent once a connection is reestablished. Messages published by other clients while this client is disconnected will be delivered to it upon reconnection if the server is able to preserve continuity. | | ||
| | SUSPENDED || A long term failure condition. A client moves to this state once it has been in the `disconnected` state for over two minutes. Developers are unable to publish messages in this state, and any queued messages are discarded. The library will attempt to reconnect every 30 seconds; an attempt can also be triggered by calling [`connect()`]{@link Connection#connect}. | |
Member
There was a problem hiding this comment.
The above edit says "The client has been disconnected..." and "you can continue to publish messages", so should this here say "The client has been in the disconnected state for over two minutes" and "you are unable to publish messages in this state"?
(I'll add that I'm not sure who "you" is here, we're talking about the client being disconnected, so is it not also the client that can or cannot publish messages?)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Implements https://ably.atlassian.net/wiki/spaces/CHN/pages/5078777859/PSRFC-32+move+resumability+decisions+to+the+server+not+the+sdk
Motivation, in short:
(also tweaked docstrings for connection states, which were just the full wording from the docs copied and pasted, and were way too verbose for docstrings)