Implement the "transient disconnect timeouts" part of the spec #48
Assignees
Labels
enhancement
New feature or improved functionality.
room-lifecycle
Related to room lifecycle (temporary label).
Comments
lawrence-forooghian
added a commit
that referenced
this issue
Sep 18, 2024
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
added a commit
that referenced
this issue
Sep 18, 2024
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
added a commit
that referenced
this issue
Sep 18, 2024
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
added a commit
that referenced
this issue
Sep 19, 2024
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
added a commit
that referenced
this issue
Sep 19, 2024
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
This was referenced Sep 20, 2024
lawrence-forooghian
added a commit
that referenced
this issue
Sep 23, 2024
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
added a commit
that referenced
this issue
Sep 23, 2024
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
added a commit
that referenced
this issue
Sep 23, 2024
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
This was referenced Sep 26, 2024
lawrence-forooghian
added a commit
that referenced
this issue
Sep 26, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. TODO btw i haven't put action descriptions in all of the test names because they might end up really long In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Resolves #53. (TODO move to next commit with the discontinuity points) [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677
lawrence-forooghian
added a commit
that referenced
this issue
Sep 26, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. TODO btw i haven't put action descriptions in all of the test names because they might end up really long In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Resolves #53. (TODO move to next commit with the discontinuity points) [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677
lawrence-forooghian
added a commit
that referenced
this issue
Sep 30, 2024
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
added a commit
that referenced
this issue
Sep 30, 2024
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
added a commit
that referenced
this issue
Sep 30, 2024
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
added a commit
that referenced
this issue
Sep 30, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. TODO btw i haven't put action descriptions in all of the test names because they might end up really long In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Resolves #53. (TODO move to next commit with the discontinuity points) [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677
lawrence-forooghian
added a commit
that referenced
this issue
Sep 30, 2024
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
added a commit
that referenced
this issue
Sep 30, 2024
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
added a commit
that referenced
this issue
Sep 30, 2024
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
added a commit
that referenced
this issue
Sep 30, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. TODO btw i haven't put action descriptions in all of the test names because they might end up really long In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Part of #53. [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677
lawrence-forooghian
added a commit
that referenced
this issue
Oct 1, 2024
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
added a commit
that referenced
this issue
Oct 1, 2024
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
added a commit
that referenced
this issue
Oct 1, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Something which I didn’t think about in 25e5052, and which I haven’t thought about here, is how actor reentrancy (i.e. the fact that when an actor-isolated method suspends via `await`, another actor-isolated method can be scheduled instead, which can potentially cause issues like state updates being interleaved in unexpected ways) might affect the room lifecycle manager. I would like to first of all implement the whole thing, specifically all of the spec points that might provide us with a mutual exclusion mechanism (i.e. the ones that tell us to wait until the current operation is complete), before assessing the situation. Have created #75 for this. Aside: I have not been consistent with the way that I’ve named the tests; the existing lifecycle manager test names have a part that describes the expected side effects. But I haven’t done that here because some of the spec points tested here have multiple side effects and the test names would become really long and hard to read. So for those ones I’ve only described the expected side effects inside the tests. I think we can live with the inconsistency for now. Part of #53. [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677
lawrence-forooghian
added a commit
that referenced
this issue
Oct 1, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Something which I didn’t think about in 25e5052, and which I haven’t thought about here, is how actor reentrancy (i.e. the fact that when an actor-isolated method suspends via `await`, another actor-isolated method can be scheduled instead, which can potentially cause issues like state updates being interleaved in unexpected ways) might affect the room lifecycle manager. I would like to first of all implement the whole thing, specifically all of the spec points that might provide us with a mutual exclusion mechanism (i.e. the ones that tell us to wait until the current operation is complete), before assessing the situation. Have created #75 for this. Aside: I have not been consistent with the way that I’ve named the tests; the existing lifecycle manager test names have a part that describes the expected side effects. But I haven’t done that here because some of the spec points tested here have multiple side effects and the test names would become really long and hard to read. So for those ones I’ve only described the expected side effects inside the tests. I think we can live with the inconsistency for now. Part of #53. [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677
lawrence-forooghian
added a commit
that referenced
this issue
Oct 1, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Something which I didn’t think about in 25e5052, and which I haven’t thought about here, is how actor reentrancy (i.e. the fact that when an actor-isolated method suspends via `await`, another actor-isolated method can be scheduled instead, which can potentially cause issues like state updates being interleaved in unexpected ways) might affect the room lifecycle manager. I would like to first of all implement the whole thing, specifically all of the spec points that might provide us with a mutual exclusion mechanism (i.e. the ones that tell us to wait until the current operation is complete), before assessing the situation. Have created #75 for this. Aside: I have not been consistent with the way that I’ve named the tests; the existing lifecycle manager test names have a part that describes the expected side effects. But I haven’t done that here because some of the spec points tested here have multiple side effects and the test names would become really long and hard to read. So for those ones I’ve only described the expected side effects inside the tests. I think we can live with the inconsistency for now. Part of #53. [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677
lawrence-forooghian
added a commit
that referenced
this issue
Oct 3, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Something which I didn’t think about in 25e5052, and which I haven’t thought about here, is how actor reentrancy (i.e. the fact that when an actor-isolated method suspends via `await`, another actor-isolated method can be scheduled instead, which can potentially cause issues like state updates being interleaved in unexpected ways) might affect the room lifecycle manager. I would like to first of all implement the whole thing, specifically all of the spec points that might provide us with a mutual exclusion mechanism (i.e. the ones that tell us to wait until the current operation is complete), before assessing the situation. Have created #75 for this. Aside: I have not been consistent with the way that I’ve named the tests; the existing lifecycle manager test names have a part that describes the expected side effects. But I haven’t done that here because some of the spec points tested here have multiple side effects and the test names would become really long and hard to read. So for those ones I’ve only described the expected side effects inside the tests. I think we can live with the inconsistency for now. Part of #53. [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677
lawrence-forooghian
added a commit
that referenced
this issue
Oct 8, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Something which I didn’t think about in 25e5052, and which I haven’t thought about here, is how actor reentrancy (i.e. the fact that when an actor-isolated method suspends via `await`, another actor-isolated method can be scheduled instead, which can potentially cause issues like state updates being interleaved in unexpected ways) might affect the room lifecycle manager. I would like to first of all implement the whole thing, specifically all of the spec points that might provide us with a mutual exclusion mechanism (i.e. the ones that tell us to wait until the current operation is complete), before assessing the situation. Have created #75 for this. Created [4] to address the `@preconcurrency import Ably` introduced by this commit. Aside: I have not been consistent with the way that I’ve named the tests; the existing lifecycle manager test names have a part that describes the expected side effects. But I haven’t done that here because some of the spec points tested here have multiple side effects and the test names would become really long and hard to read. So for those ones I’ve only described the expected side effects inside the tests. I think we can live with the inconsistency for now. Part of #53. [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677 [4] ably/ably-cocoa#1987
lawrence-forooghian
added a commit
that referenced
this issue
Oct 8, 2024
Implements points CHA-RL4* from same spec as referenced in e70ee44. In addition to the TODOs added in the code (all of which refer either to existing GitHub issues or questions on the spec, for which we have #66 as a catch-all issue), I’ve also not done: - CHA-RL4a2 — I don’t understand the meaning of “has not yet successfully managed to attach its Realtime Channel”, asked about it in [1] - CHA-RL4b2 — seems redundant, asked about it in [2] - CHA-RL4b3, CHA-RL4b4 — seem redundant, asked about it in [3] - CHA-RL4b5, CHA-RL4b6, CHA-RL4b7 — these relate to transient disconnect timeouts, so will do them in #48 Something which I didn’t think about in 25e5052, and which I haven’t thought about here, is how actor reentrancy (i.e. the fact that when an actor-isolated method suspends via `await`, another actor-isolated method can be scheduled instead, which can potentially cause issues like state updates being interleaved in unexpected ways) might affect the room lifecycle manager. I would like to first of all implement the whole thing, specifically all of the spec points that might provide us with a mutual exclusion mechanism (i.e. the ones that tell us to wait until the current operation is complete), before assessing the situation. Have created #75 for this. Created [4] to address the `@preconcurrency import Ably` introduced by this commit. Aside: I have not been consistent with the way that I’ve named the tests; the existing lifecycle manager test names have a part that describes the expected side effects. But I haven’t done that here because some of the spec points tested here have multiple side effects and the test names would become really long and hard to read. So for those ones I’ve only described the expected side effects inside the tests. I think we can live with the inconsistency for now. Part of #53. [1] https://github.com/ably/specification/pull/200/files#r1775552624 [2] https://github.com/ably/specification/pull/200/files#r1777212960 [3] https://github.com/ably/specification/pull/200/files#r1777365677 [4] ably/ably-cocoa#1987
lawrence-forooghian
added
the
room-lifecycle
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Split from #28.
The meaning of the parts of the spec that refer to "transient disconnect timeouts" wasn’t clear to me on my first pass of implementing the spec, so I decided to defer it.
Understand and implement.
Spec points relating to the creation of transient disconnect timeouts:
ATTACHINGand no transient disconnect timeout exists for the contributor, then a timeout is created with a 5 second limit. Upon timeout, the room status is transitioned toATTACHING, using thereasonfrom the initial channel state change as the error for the transition.ATTACHINGand a transient disconnect timeout exists for the contributor, then no action is needed.Spec points relating to the cancellation of transient disconnect timeouts:
DETACHINGstatus and any transient disconnect timeouts cleared.RELEASINGstatus any any transient disconnect timeouts shall be cleared.FAILED, then the room status shall be transitioned toFAILED, using thereasonfor the channel state change as theerrorfor the room status change. Alltransient disconnect timeoutsare cancelled and any non-detached contributors are detached.ATTACHEDand a transient disconnect timeout exists for the contributor, the timeout is cleared.SUSPENDED, then the room status is transitioned toSUSPENDED, using thereasonof the channel state change as the error. Any transient disconnect timeouts are cancelled and the room enters theRETRYloop.┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: