[ECO-4952] Start implementing room lifecycle spec #3
Conversation
This file contains 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
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 ably-labs#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 ably-labs#52) - Lifecycle behaviour relating to “transient disconnect timeouts” (created ably-labs#48) - Lifecycle behaviour that occurs “asynchronously” outside an operation (created ably-labs#50) - CHA-RL1g2, which refers to emitting “discontinuity events” which are a concept not yet implemented; this will come in ably-labs#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 ably-labs#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 ably-labs#28. [1] ably/specification#200 [2] https://github.com/ably/ably-js/blob/main/CONTRIBUTING.md#tests-alignment-with-the-ably-features-specification
|
This is an experiment review for experiment Experiment configurationreview_config:
# User configuration for the review
# - benchmark - use the user config from the benchmark reviews
# - <value> - use the value directly
user_review_config:
enable_ai_review: true
enable_rule_comments: false
enable_complexity_comments: false
enable_security_comments: false
enable_tests_comments: false
enable_comment_suggestions: false
enable_functionality_review: false
enable_pull_request_summary: false
enable_review_guide: true
enable_approvals: false
ai_review_config:
# The model responses to use for the experiment
# - benchmark - use the model responses from the benchmark reviews
# - llm - call the language model to generate responses
model_responses:
comments_model: benchmark
comment_area_model: benchmark
comment_validation_model: benchmark
comment_suggestion_model: benchmark
complexity_model: benchmark
functionality_model: benchmark
security_model: benchmark
tests_model: benchmark
pull_request_summary_model: benchmark
review_guide_model: llm
overall_comments_model: benchmark
# The pull request dataset to run the experiment on
pull_request_dataset:
- https://github.com/sourcery-ai/core/pull/4607
- https://github.com/sourcery-ai/core/pull/4631
- https://github.com/sourcery-ai/core/pull/4647
# CodeRabbit examples:
- https://github.com/2lambda123/-Orange-OpenSource-oorobot/pull/15
- https://github.com/2lambda123/galaxyproject-galaxy/pull/12
- https://github.com/a0v0/avtoolz/pull/79
- https://github.com/adityask98/Hotaru/pull/10
- https://github.com/agdas/vscode/pull/2
- https://github.com/agluszak/hirschgarten/pull/2
- https://github.com/alexsnow348/insightface/pull/46
- https://github.com/alikuxac/utilities/pull/10
- https://github.com/AlphaDev87/timba-api/pull/49
- https://github.com/AngeloTadeucci/Maple2/pull/239
- https://github.com/AngeloTadeucci/Maple2.File/pull/36
- https://github.com/AngeloTadeucci/Maple2/pull/233
# Examples where CodeRabbit does not generate diagrams
- https://github.com/baptisteArno/typebot.io/pull/1778
- https://github.com/btipling/foundations/pull/33
- https://github.com/btipling/foundations/pull/31
- https://github.com/chintu-777/jaeger/pull/1
- https://github.com/coji/remix-docs-ja/pull/55
- https://github.com/DaveMBush/SmartNgRX/pull/622
- https://github.com/DaveMBush/SmartNgRX/pull/481
- https://github.com/dkittle/party-connections/pull/6
- https://github.com/Drajad-Kusuma-Adi/onstudy-backend/pull/6
- https://github.com/imaami/libcanth/pull/2
# Requested by Tim
- https://github.com/2lambda123/-Orange-OpenSource-oorobot/pull/15
- https://github.com/2lambda123/galaxyproject-galaxy/pull/12
- https://github.com/a0v0/avtoolz/pull/79
- https://github.com/adityask98/Hotaru/pull/10
- https://github.com/agdas/vscode/pull/2
- https://github.com/agluszak/hirschgarten/pull/2
- https://github.com/4DNucleome/PartSeg/pull/1183
- https://github.com/ably/ably-cocoa/pull/1973
- https://github.com/ably-labs/ably-chat-swift/pull/54
- https://github.com/ably-labs/ably-chat-swift/pull/35
# Questions to ask to label the review comments
review_comment_labels: []
# - label: correct
# question: Is this comment correct?
# Benchmark reviews generated by running
# python -m scripts.experiment benchmark <experiment_name>
benchmark_reviews:
- dataset_pull_request: https://github.com/sourcery-ai/core/pull/4607
review_pull_request: https://github.com/sourcery-ai-experiments/core/pull/338
- dataset_pull_request: https://github.com/sourcery-ai/core/pull/4631
review_pull_request: https://github.com/sourcery-ai-experiments/core/pull/339
- dataset_pull_request: https://github.com/sourcery-ai/core/pull/4647
review_pull_request: https://github.com/sourcery-ai-experiments/core/pull/340
- dataset_pull_request: https://github.com/2lambda123/-Orange-OpenSource-oorobot/pull/15
review_pull_request: https://github.com/sourcery-ai-experiments/-Orange-OpenSource-oorobot/pull/2
- dataset_pull_request: https://github.com/2lambda123/galaxyproject-galaxy/pull/12
review_pull_request: https://github.com/sourcery-ai-experiments/galaxyproject-galaxy/pull/1
- dataset_pull_request: https://github.com/adityask98/Hotaru/pull/10
review_pull_request: https://github.com/sourcery-ai-experiments/Hotaru/pull/2
- dataset_pull_request: https://github.com/agdas/vscode/pull/2
review_pull_request: https://github.com/sourcery-ai-experiments/vscode/pull/3
- dataset_pull_request: https://github.com/agluszak/hirschgarten/pull/2
review_pull_request: https://github.com/sourcery-ai-experiments/hirschgarten/pull/2
- dataset_pull_request: https://github.com/alikuxac/utilities/pull/10
review_pull_request: https://github.com/sourcery-ai-experiments/utilities/pull/2
- dataset_pull_request: https://github.com/AlphaDev87/timba-api/pull/49
review_pull_request: https://github.com/sourcery-ai-experiments/timba-api/pull/2
- dataset_pull_request: https://github.com/AngeloTadeucci/Maple2/pull/239
review_pull_request: https://github.com/sourcery-ai-experiments/Maple2/pull/3
- dataset_pull_request: https://github.com/AngeloTadeucci/Maple2.File/pull/36
review_pull_request: https://github.com/sourcery-ai-experiments/Maple2.File/pull/2
- dataset_pull_request: https://github.com/AngeloTadeucci/Maple2/pull/233
review_pull_request: https://github.com/sourcery-ai-experiments/Maple2/pull/4
- dataset_pull_request: https://github.com/baptisteArno/typebot.io/pull/1778
review_pull_request: https://github.com/sourcery-ai-experiments/typebot.io/pull/1
- dataset_pull_request: https://github.com/btipling/foundations/pull/33
review_pull_request: https://github.com/sourcery-ai-experiments/foundations/pull/1
- dataset_pull_request: https://github.com/btipling/foundations/pull/31
review_pull_request: https://github.com/sourcery-ai-experiments/foundations/pull/2
- dataset_pull_request: https://github.com/chintu-777/jaeger/pull/1
review_pull_request: https://github.com/sourcery-ai-experiments/jaeger/pull/1
- dataset_pull_request: https://github.com/coji/remix-docs-ja/pull/55
review_pull_request: https://github.com/sourcery-ai-experiments/remix-docs-ja/pull/1
- dataset_pull_request: https://github.com/DaveMBush/SmartNgRX/pull/622
review_pull_request: https://github.com/sourcery-ai-experiments/SmartNgRX/pull/1
- dataset_pull_request: https://github.com/DaveMBush/SmartNgRX/pull/481
review_pull_request: https://github.com/sourcery-ai-experiments/SmartNgRX/pull/2
- dataset_pull_request: https://github.com/dkittle/party-connections/pull/6
review_pull_request: https://github.com/sourcery-ai-experiments/party-connections/pull/1
- dataset_pull_request: https://github.com/Drajad-Kusuma-Adi/onstudy-backend/pull/6
review_pull_request: https://github.com/sourcery-ai-experiments/onstudy-backend/pull/1
- dataset_pull_request: https://github.com/imaami/libcanth/pull/2
review_pull_request: https://github.com/sourcery-ai-experiments/libcanth/pull/1
- dataset_pull_request: https://github.com/4DNucleome/PartSeg/pull/1183
review_pull_request: https://github.com/sourcery-ai-experiments/PartSeg/pull/2
- dataset_pull_request: https://github.com/ably/ably-cocoa/pull/1973
review_pull_request: https://github.com/sourcery-ai-experiments/ably-cocoa/pull/1
- dataset_pull_request: https://github.com/ably-labs/ably-chat-swift/pull/54
review_pull_request: https://github.com/sourcery-ai-experiments/ably-chat-swift/pull/1
- dataset_pull_request: https://github.com/ably-labs/ably-chat-swift/pull/35
review_pull_request: https://github.com/sourcery-ai-experiments/ably-chat-swift/pull/2
|
Reviewer's Guide by SourceryThis pull request implements a significant portion of the room lifecycle specification for the Ably Chat SDK. It introduces a new File-Level Changes
Sequence DiagramsATTACH Operation SequencesequenceDiagram
participant Client
participant RLM as RoomLifecycleManager
participant Contributor
Client->>RLM: performAttachOperation()
RLM->>RLM: changeStatus(to: .attaching)
loop For each contributor
RLM->>Contributor: attach()
alt Attach succeeds
Contributor-->>RLM: Success
else Attach fails
Contributor-->>RLM: Error
RLM->>RLM: changeStatus(to: .suspended or .failed)
RLM-->>Client: Throw error
end
end
RLM->>RLM: changeStatus(to: .attached)
RLM-->>Client: Operation complete
DETACH Operation SequencesequenceDiagram
participant Client
participant RLM as RoomLifecycleManager
participant Contributor
Client->>RLM: performDetachOperation()
RLM->>RLM: changeStatus(to: .detaching)
loop For each contributor
RLM->>Contributor: detach()
alt Detach succeeds
Contributor-->>RLM: Success
else Detach fails
Contributor-->>RLM: Error
RLM->>RLM: Retry logic
end
end
alt All detaches successful
RLM->>RLM: changeStatus(to: .detached)
RLM-->>Client: Operation complete
else Any detach failed
RLM->>RLM: changeStatus(to: .failed)
RLM-->>Client: Throw error
end
Tips
|
SourceryAI
reviewed
Sep 20, 2024
There was a problem hiding this comment.
Hey @ruancomelli - I've reviewed your changes - here's some feedback:
Overall Comments:
- Consider breaking down some of the larger functions in RoomLifecycleManager (e.g., performAttachOperation, performDetachOperation) into smaller, more focused functions to improve readability and maintainability.
- The error handling approach with custom error types and extensive mapping is complex. Consider exploring a more unified error handling strategy in the future to reduce potential inconsistencies.
Here's what I looked at during the review
- 🟡 General issues: 3 issues found
- 🟡 Documentation: 1 issue found
Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.
Comment on lines
+19
to
+28
| case messagesAttachmentFailed = 102_001 | ||
| case presenceAttachmentFailed = 102_002 | ||
| case reactionsAttachmentFailed = 102_003 | ||
| case occupancyAttachmentFailed = 102_004 | ||
| case typingAttachmentFailed = 102_005 | ||
|
|
||
| case messagesDetachmentFailed = 102_050 | ||
| case presenceDetachmentFailed = 102_051 | ||
| case reactionsDetachmentFailed = 102_052 | ||
| case occupancyDetachmentFailed = 102_053 |
There was a problem hiding this comment.
suggestion: Consider consolidating error types for attachment and detachment failures
The current approach of having separate error codes for each feature's attachment and detachment failures leads to repetitive code. Consider creating a more generic error type with associated values for the feature and operation type (attach/detach). This could simplify the ErrorCode enum and make it easier to maintain.
Comment on lines
+257
to
+260
| // TODO: Make this not trap in the case where the Task is cancelled (as part of the broader https://github.com/ably-labs/ably-chat-swift/issues/29 for handling task cancellation) | ||
| // TODO: what's the correct wait time? (https://github.com/ably/specification/pull/200#discussion_r1763822207) | ||
| // swiftlint:disable:next force_try | ||
| try! await clock.sleep(nanoseconds: 1_000_000_000) |
There was a problem hiding this comment.
suggestion (bug_risk): Avoid force unwrapping in sleep call
Force unwrapping should be avoided to prevent potential crashes. Consider using optional chaining or a guard statement instead. For example, you could use try? await clock.sleep(nanoseconds: 1_000_000_000) or handle the error explicitly if it's important for the operation.
| // @spec CHA-RL3d | ||
| // @specOneOf(1/2) CHA-RL3e | ||
| // @spec CHA-RL3g | ||
| func test_release_detachesAllNonFailedContributors() async throws { |
There was a problem hiding this comment.
suggestion (testing): Consider breaking down large test methods
This test method, along with several others in this file, is quite long and tests multiple behaviors. Consider breaking it down into smaller, more focused tests. This would improve readability and make it easier to identify which specific functionality is failing if a test breaks.
| self.clock = clock | ||
| } | ||
|
|
||
| // TODO: clean up old subscriptions (https://github.com/ably-labs/ably-chat-swift/issues/36) |
There was a problem hiding this comment.
suggestion: Consider moving TODOs to issue tracker
There are several TODO comments throughout the code. While it's good to mark areas for future improvement, consider moving these TODOs to your issue tracker (which you've already started doing for some). This keeps the code cleaner and ensures that these tasks are properly tracked and prioritized.
| @@ -28,3 +28,46 @@ To check formatting and code quality, run `swift run BuildTool lint`. Run with ` | |||
| - We should aim to make it easy for consumers of the SDK to be able to mock out the SDK in the tests for their own code. A couple of things that will aid with this: | |||
| - Describe the SDK’s functionality via protocols (when doing so would still be sufficiently idiomatic to Swift). | |||
| - When defining a `struct` that is emitted by the public API of the library, make sure to define a public memberwise initializer so that users can create one to be emitted by their mocks. (There is no way to make Swift’s autogenerated memberwise initializer public, so you will need to write one yourself. In Xcode, you can do this by clicking at the start of the type declaration and doing Editor → Refactor → Generate Memberwise Initializer.) | |||
| - When writing code that implements behaviour specified by the Chat SDK features spec, add a comment that references the identifier of the relevant spec item. | |||
|
|
|||
| ### Testing guidelines | |||
There was a problem hiding this comment.
suggestion (documentation): Consider adding a brief explanation of the purpose of spec tags
It might be helpful to briefly explain why these spec tags are used at the beginning of the 'Attributing tests to a spec point' section. This would provide immediate context for developers.
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.
Note: This is based on top of ably-labs#60; please review that one first.
This is based on ably/specification#200 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, andRELEASEoperations. I have not yet implementedRETRYsince it’s quite different to those three and I wanted to get eyes on this first chunk of work; have created ably-labs#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):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 ably-labs#47 for doing this integration work.
The
@spec…tags are based on the on the JS rules @8c9ce8b, but I camel-cased them and also decided that:Part of ably-labs#28.
Summary by CodeRabbit
New Features
RoomLifecycleManagerto manage chat room contributor states effectively.SimpleClockprotocol to facilitate asynchronous task management in testing.RoomLifecycleContributorChannelfor testing purposes.Bug Fixes
Tests
RoomLifecycleManagerto ensure robust lifecycle management of chat rooms.