Merge integration/protocol-v6 into main#125
Conversation
Implements the ObjectOperation field changes specified in spec commit 47a9d51. Integration test updates ported from JS commit fdc33cb (excluding the public API changes, since we don't yet expose any sort of ObjectOperation, nor does the spec). Note that this is the first time that we've had to bump the protocol version in a way that affects LiveObjects, and here we're following the process documented in the pinned plugin-support commit. Also note that this spec change formalises the then-unspecified change that we made in ec37cca. The downside of getting Claude to do this sort of enormous mechanical change is that for a human to review its changes with 100% confidence — in particular, all the spec point reference updates — would require almost as much work as just doing it by hand. So I haven't reviewed it with 100% confidence. I've: - glanced over the whole diff a few times - spot-checked that the most interesting behaviours are implemented and tested (specifically, the creation of the initial value JSON, the retention of the derivedFrom op and its usage when applying the create op) - prompted Claude to review its own work from scratch a few times Beyond that, I'm relying on the fact that the barely-changed integration tests continue to pass. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Will be useful for some upcoming tests. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Give the sync objects pool its own type instead of using a bare [SyncObjectsPoolEntry] array. This makes the concept explicit and is preparation for implementing partial object sync, which will expand the capabilities of this type. I wouldn't pay too much attention to the tests; they'll be replaced soon. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Port the two integration tests added in ably-js commit b20d3ed: - OBJECT_SYNC sequence builds object tree across multiple sync messages - OBJECT_SYNC does not break when receiving an unknown object type Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Implements the changes from spec commits 1f22417, 9f4d7de, and 963ec30, which allow the server to split a large object across multiple OBJECT_SYNC protocol messages. The new integration test is ported from ably-js commit d0bc431. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
[AIT-322] Support the protocol v6 `ObjectMessage` structure
Requested by Evgenii in code review, for readability. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
[AIT-207] Partial object sync
Make everything go via a single method that implements the RTLM4 definition.
Per spec commit a9f839b. Integration tests ported from JS commit d2ddac6. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
[AIT-454] Implement `MAP_CLEAR` operation
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (25)
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 |
|
Will merge this one too |
No description provided.