Docs for realtime update/delete, new return type, adding append, and rest api changes for public preview release #3044
Conversation
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
Adds support for data-type="public-preview" to the Aside component to support labelling with the new Public Preview release stage. SEE: PDR-086
|
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 ✨ 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 |
GregHolmes
requested changes
Dec 22, 2025
Contributor
GregHolmes
left a comment
GregHolmes
left a comment
There was a problem hiding this comment.
Couple small changes needed.
I've added a comment on the Append to a message section as it feels like it's a lot of text that mostly compares appendMessage with updateMessage. Would love to know what you think on that part?
| MESSAGE_UPDATE, // 1 | ||
| MESSAGE_DELETE, // 2 | ||
| META, // 3 | ||
| MESSAGE_SUMMARY // 4 |
Contributor
There was a problem hiding this comment.
Suggested change
| MESSAGE_SUMMARY // 4 | |
| MESSAGE_SUMMARY, // 4 |
| ARTMessageActionUpdate, | ||
| ARTMessageActionDelete, | ||
| ARTMessageActionMeta, | ||
| ARTMessageActionMessageSummary |
Contributor
There was a problem hiding this comment.
Suggested change
| ARTMessageActionMessageSummary | |
| ARTMessageActionMessageSummary, |
| A successful request returns the updated @Message@ object with the new version information. | ||
|
|
||
| See [MessageAction](/docs/api/realtime-sdk/types#message-action) for the possible values of the `action` enum. | ||
| Returns an [`UpdateDeleteResult`](/docs/api/realtime-sdk/types#update-delete-result), an object with a single `versionSerial` field: the serial of the version of the updated, deleted, or appended message, or `null` if the message was superseded by a subsequent update before it could be published. |
Contributor
There was a problem hiding this comment.
Suggested change
| Returns an [`UpdateDeleteResult`](/docs/api/realtime-sdk/types#update-delete-result), an object with a single `versionSerial` field: the serial of the version of the updated, deleted, or appended message, or `null` if the message was superseded by a subsequent update before it could be published. | |
| Returns an [`UpdateDeleteResult`](/docs/api/realtime-sdk/types#update-delete-result) object with a single `versionSerial` field: the serial of the version of the updated, deleted, or appended message, or `null` if the message was superseded by a subsequent update before it could be published. |
Comment on lines
+226
to
+230
| Unlike `updateMessage()` which replaces the data field, `appendMessage()` concatenates the new data to the existing message's (string or binary) data. This is useful for building up message content incrementally, for example in streaming or gradual message building scenarios. Other fields (`name`, `extras`) will replace the previous values if provided, similar to update mixin semantics. | ||
|
|
||
| The message is identified by its `serial`, which is populated by Ably. To append to a message, you need its serial - you can get this either from the return value of `publish()`, from a received message via subscription, or by querying history. | ||
|
|
||
| When Ably receives an append, we will concatenate the provided data with the current latest version and calculate the updated full (non-incremental) version of the message. That full version of the message is what will be stored in [History](/docs/storage-history/history) as the most recent version, with an action of `message.update`, so someone paging through the history of a channel will never need to do any concatenation themselves, they will just get the full message. Similarly, when attaching to a channel using [rewind](/docs/channels/options/rewind) to get recent messages you will receive only one version of each message, the latest version with the full concatenated data, which means you can specify e.g. `rewind=10` to get the most recent 10 full, distinct messages. Only realtime subscribers receiving live messages will receive the incremental appends (and they can pass a [channel param](/docs/channels/options#append-mode) to request full versions if they want). |
Contributor
There was a problem hiding this comment.
Could most of this be summarised into a comparison table? It feels like we're comparing the two in these 3 paragraphs creating 4 chunks of text that may be unnecessary?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
NB: not for merging until we do a prod rollout of the serverside components of this change