[DX-879] [DX-880] Addresses discontinuity docs gap from llm-eval docs audit#3232
[DX-879] [DX-880] Addresses discontinuity docs gap from llm-eval docs audit#3232umair-ably merged 2 commits intomainfrom
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
5919b84 to
460407b
Compare
| const { off } = room.onDiscontinuity((reason) => { | ||
| console.log('Discontinuity detected:', reason); | ||
| // Fetch missed messages using history | ||
| room.messages.history({ orderBy: OrderBy.NewestFirst, limit: 50 }).then((history) => { |
There was a problem hiding this comment.
You're likely to want to use historyBeforeSubscribe based on your messages subscription here
| @@ -0,0 +1,170 @@ | |||
| --- | |||
There was a problem hiding this comment.
I would split this guide into Pub/Sub and Chat - they're handled quite differently so it would be weird to have someone expecting to find Chat to be greeted by Pub/Sub.
| Discontinuity occurs when the Ably SDK cannot guarantee that all messages have been delivered to the client. The most common causes are: | ||
|
|
||
| - Network disconnection lasting longer than two minutes. Ably preserves [connection state](/docs/connect/states#connection-state-recovery) for up to two minutes. Beyond this window, Ably cannot guarantee message continuity. | ||
| - Server-initiated continuity loss. Operational events such as cluster rebalancing may cause a partial loss of message continuity, even if the client remained connected. |
There was a problem hiding this comment.
Also when outbound rate limits are hit
| <Code> | ||
| ```javascript | ||
| async function recoverMissedMessages(channel) { | ||
| const history = await channel.history({ untilAttach: true }); |
There was a problem hiding this comment.
This example is incomplete - untilAttach will allow you to paginate all messages up until the point of attachment (or re-attachment, in this case). However it is the users responsibility to work out how far back they need to go with their history query (e.g. using timebounds, then checking message IDs or serials for things they've already seen before).
There is also no guarantee that all missed messages are in one page, so multiple pages may be required (not shown here).
| </Code> | ||
|
|
||
| <Aside data-type="important"> | ||
| Subscribe to the channel before making a history request with `untilAttach` set to `true`. Calling `subscribe()` implicitly attaches the channel, which populates the serial number used by the `untilAttach` parameter. This guarantees that messages from the point of attachment onwards are received via the subscription, while prior messages are retrieved via history. |
There was a problem hiding this comment.
Only if the attachOnSubscribe setting is true.
| ``` | ||
| </Code> | ||
|
|
||
| You can also use [`historyBeforeSubscribe()`](/docs/chat/rooms/history#subscribe) to retrieve messages from the point at which your listener was subscribed, ensuring no overlap between historical and live messages. |
There was a problem hiding this comment.
From the point at which it was re-subscribed. The attachment point changes post-resume. historyBeforeSubscribe is preferred for Chat over history as it guarantees you don't miss anything.
A complication you have to consider with Chat is that message UPDATEs and DELETEs may have happened on the channel during the discontinuity period, which wouldn't be picked up by simply appending messages to the UI.
In this situation, you want to refresh the entire Chat message state.
ce4a09d to
c7c8a1a
Compare
Description
Addresses discontinuity docs gap from llm-eval docs audit
Checklist