Implement the `RETRY` room lifecycle operation #51

lawrence-forooghian · 2024-09-18T17:11:01Z

Split from #28.

Implement CHA-RL5
~~Implement the part of CHA-RL1h3 and CHA-RL4b9 which triggers a RETRY.~~ — will do this in Trigger the RETRY operation where spec says to #50

┆Issue is synchronized with this Jira Task by Unito

The text was updated successfully, but these errors were encountered:

This is based on [1] at b4a495e. It’s generated some questions, which I’ve asked on that PR. Note that the spec has been through a few revisions since I started implementing this; I’ve tried to keep everything in sync but some older stuff might still be accidentally there. I’ve implemented most of the specified behaviour for the ATTACH, DETACH, and RELEASE operations. I have not yet implemented RETRY since it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created #51 for implementing it. Of the operations that I have implemented, I have not implemented the following (this is accurately reflected by the @SPEC… tags in the tests): - Lifecycle behaviour that relates to another ongoing operation (created #52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created #48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created #50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in #53. The room lifecycle manager introduced by this commit is currently a standalone object, which is not integrated with the rest of the SDK. I’ve created #47 for doing this integration work. The @SPEC… tags are based on the on the JS rules [2] @ 8c9ce8b, but I camel-cased them and also decided that: - if a test doesn't relate to a spec point, it doesn't need any markers - there should be a way to know that a spec point is tested across multiple tests - there should be a way of marking a spec point as implemented but not tested (so that can show up differently in reporting; important given that we’re also going to use this report as a to-do list of what still needs to be implemented) Part of #28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification

lawrence-forooghian · 2024-10-09T19:03:17Z

Just took a look at the spec points for this and there a couple of things that I don't understand, to the point that it's not really worth me starting on this one yet. I’ve put questions on the spec and asked Andy if he could take a look at the ones that are most likely to unblock me. Will wait to hear back.

Based on the spec referenced in 20f21c7. The RETRY part of this spec was quite unclear, and I asked quite a few questions on the PR to understand it better, so the behaviour implemented here is based on the spec plus Andy’s answers to my questions (I’ve linked to the discussions in the code and / or tests). Recently (i.e. after most of this commit was already implemented, Andy has updated the spec with answers to these questions, but in the interests of not dragging out the current task, I’ll incorporate these updates in #66. The internal triggering of the RETRY operation (as specified by CHA-RL1h3 and CHA-RL4b9) will come in #50. Resolves #51.

WIP updating to be based on 0e5ab98 Based on the spec referenced in 20f21c7. The RETRY part of this spec was quite unclear, and I asked quite a few questions on the PR to understand it better, so the behaviour implemented here is based on the spec plus Andy’s answers to my questions (I’ve linked to the discussions in the code and / or tests). Recently (i.e. after most of this commit was already implemented, Andy has updated the spec with answers to these questions, but in the interests of not dragging out the current task, I’ll incorporate these updates in #66. The internal triggering of the RETRY operation (as specified by CHA-RL1h3 and CHA-RL4b9) will come in #50. Resolves #51.