Release 2.28.0 - #2292
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. WalkthroughThe release documents end-to-end encryption for annotation data when channel cipher options are configured. It updates the changelog and changes package and React hooks version identifiers from ChangesAnnotation encryption release
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to This release updates version metadata and documents the annotation encryption behavior change; no actionable merge-blocking risk remains beyond normal checks and review. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
The `publish` docstrings on RealtimeAnnotations and RestAnnotations stated that annotation data is never encrypted, and gave the server's need to read it for summarisation as the reason. Both stopped being true when annotation publishing started passing the channel's cipher options through. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
d6ab179 to
debdc51
Compare
Bumps the version to 2.28.0 in
package.json,package-lock.jsonandsrc/platform/react-hooks/src/AblyReactHooks.ts, and adds the2.28.0entry toCHANGELOG.md.The change that drove the release is #2277: annotation
datapayloads were published in plaintext even on channels with a cipher configured, becauseAnnotation.encode()passed an empty options object to the sharedencode()helper. Annotations were the only message type whose publish path did not apply the channel's encryption.Also included is a docstring correction that #2277 should have carried. The four
publishdocstrings onRealtimeAnnotationsandRestAnnotationsstated that annotation data is never encrypted, and gave the server's need to read it for summarisation as the reason. Both halves stopped being true once #2277 landed, and the reason had been stale considerably longer — see below.Why a minor rather than a patch
Not for wire compatibility: the decode path already passed
channelOptionsthrough before #2277, so the change is one-directional and compatible both ways. A 2.27.0 subscriber decrypts an annotation published by 2.28.0, and a 2.28.0 subscriber handles a plaintext annotation from an older publisher unchanged.The reason is that the old behaviour was documented in
ably.d.ts, so anything built against that documented guarantee — a server-side integration parsing annotationdataon a ciphered channel — now receives ciphertext. A patch is the release people apply without reading the changelog.Worth recording that the documented rationale was already obsolete. The server needed to read
dataonly formultiple.v1as originally imagined, which used payloads like{"count":1}. That API was changed before annotations went public, specifically so aggregation did not read payloads, preserving the "Ably never reads your payload" property and making end-to-end encryption possible. That landed in ably-js in April 2025 with thecountfield, but enabling encryption was missed at the time. Summarisation readstype/name/countand neverdata, so encrypting it costs nothing server-side.PRs included since 2.27.0
User-facing (in changelog)
The branch also carries an internal replacement of
CipherOptionswith anEncryptedChannelOptionstype narrowed by anisEncrypted()guard, a fix forencode()testingcipherwithoutchannelCipherbefore dereferencing it, and removal of some anti-flake sleeps from the annotation tests. None are user-facing, and all merged as part of #2277 rather than separately.Summary by CodeRabbit