-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RTL13] Fix existing impl. for server sent DETACH #1054
base: main
Are you sure you want to change the base?
Conversation
WalkthroughThe pull request modifies the Changes
Possibly related issues
Poem
Finishing Touches
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
2479c47
to
e8cb69a
Compare
e8cb69a
to
9b46c4f
Compare
9b46c4f
to
9eb265b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (2)
lib/src/test/java/io/ably/lib/test/realtime/RealtimeChannelTest.java (2)
1739-1745
: Refactor state sequence assertions to improve test robustnessAsserting the exact size and order of
channelStates
can make the test brittle to future changes in state transitions. Consider verifying the sequence of key states without hardcoding their positions.Apply this diff to refactor the assertions:
- Assert.assertEquals(4, channelStates.size()); - Assert.assertEquals(ChannelState.attaching, channelStates.get(0)); - Assert.assertEquals(ChannelState.attached, channelStates.get(1)); - Assert.assertEquals(ChannelState.attaching, channelStates.get(2)); - Assert.assertEquals(ChannelState.attached, channelStates.get(3)); + List<ChannelState> expectedStates = Arrays.asList( + ChannelState.attaching, + ChannelState.attached, + ChannelState.attaching, + ChannelState.attached + ); + Assert.assertTrue(channelStates.containsAll(expectedStates));
1795-1802
: Refactor assertions to enhance test maintainabilityDirectly asserting the size and exact order of
channelStates
may lead to brittle tests. It's advisable to verify the presence and order of important states to make the test more resilient to future changes.Consider the following refactor:
- Assert.assertEquals(5, channelStates.size()); - Assert.assertEquals(ChannelState.attaching, channelStates.get(0)); - Assert.assertEquals(ChannelState.attached, channelStates.get(1)); - Assert.assertEquals(ChannelState.suspended, channelStates.get(2)); - Assert.assertEquals(ChannelState.attaching, channelStates.get(3)); - Assert.assertEquals(ChannelState.attached, channelStates.get(4)); + List<ChannelState> expectedStates = Arrays.asList( + ChannelState.attaching, + ChannelState.attached, + ChannelState.suspended, + ChannelState.attaching, + ChannelState.attached + ); + Assert.assertTrue(channelStates.containsAll(expectedStates));
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
lib/src/main/java/io/ably/lib/realtime/ChannelBase.java
(2 hunks)lib/src/test/java/io/ably/lib/test/realtime/RealtimeChannelTest.java
(3 hunks)
🔇 Additional comments (5)
lib/src/main/java/io/ably/lib/realtime/ChannelBase.java (2)
247-248
: Appropriate handling of connection states during attach
The added check for ConnectionState.connecting
and ConnectionState.disconnected
ensures that the channel correctly handles attaching when the connection is in these states, enhancing robustness during state transitions.
1299-1304
: Correct reattach logic on unexpected DETACH in attached or suspended states
The implementation properly reattaches the channel when an unexpected DETACH is received while the channel is in the attached
or suspended
state, adhering to the specification RTL13a.
lib/src/test/java/io/ably/lib/test/realtime/RealtimeChannelTest.java (3)
29-29
: Added necessary import statements
The addition of org.junit.Assert
import statements supports the use of assertion methods in the test cases, ensuring code clarity and reducing the need for fully qualified class names.
Line range hint 1707-1751
: Comprehensive test for server-initiated DETACH in attached state
The new test server_initiated_detach_for_attached_channel
effectively verifies the channel state transitions when a server-initiated DETACH is received while the channel is attached, ensuring correct reattachment behavior as per RTL13a.
1753-1802
: Added test for server-initiated DETACH in suspended state
The new test server_initiated_detach_for_suspended_channel
correctly checks the channel's behavior upon receiving a server-initiated DETACH while in the suspended state, ensuring compliance with specification RTL13a.
1. Removed use of explicitly setting detached state 2. Fixed attachWithTimeout method call, set forcedAttach flag to true 3. Updated tests to track channel state changes on server sent DETACH
…RTL5g) 1. Added missing callCompletionListenerError when detachImpl throws exception on invalid connection state 2. Added separate test case for the spec RTL5g 3. Annotated channel detach tests with appropriate spec
9eb265b
to
a6bbcb2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, but we’re still not fully spec-compliant. The error reason from the detach message should be propagated in the state change
1. Added impl. to store server sent detach error to avoid modifying `attachWithTimeout` method signature 2. Updated test assertions for spec RTL13a accordingly
Fixed 1360bc6 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 0
🧹 Nitpick comments (3)
lib/src/test/java/io/ably/lib/test/realtime/RealtimeChannelTest.java (3)
Line range hint
1791-1840
: Consider a more descriptive test name.The test thoroughly validates the channel state transitions and error propagation. However, consider renaming it to better describe the test scenario, e.g.,
test_server_initiated_detach_transitions_attached_channel_through_attaching_to_attached
.
Line range hint
1849-1902
: Consider extracting common setup code.The test thoroughly validates the channel state transitions and error propagation. However, there's significant setup code duplication with
server_initiated_detach_for_attached_channel
. Consider extracting the common setup into a helper method.+ private void setupChannelAndWaitForState(String channelName, ChannelState targetState, ErrorInfo error) throws AblyException { + Channel channel = ably.channels.get(channelName); + ChannelWaiter channelWaiter = new ChannelWaiter(channel); + channel.attach(); + channelWaiter.waitFor(ChannelState.attached); + if (error != null) { + channel.setSuspended(error, true); + channelWaiter.waitFor(targetState); + } + return new ChannelTestContext(channel, channelWaiter); + }
1164-1231
: Enhance assertion messages for better test failure diagnostics.The test thoroughly validates error handling in detach operations. However, the assertions could benefit from more descriptive messages to help diagnose test failures.
- assertFalse(detachWaiter1.success); - assertNotNull(detachWaiter1.error); - assertEquals("Connection is closing", detachWaiter1.error.message); - assertEquals(80001, detachWaiter1.error.code); + assertFalse("Detach should fail when connection is closing", detachWaiter1.success); + assertNotNull("Error should be present for failed detach", detachWaiter1.error); + assertEquals("Error message should indicate connection closing", "Connection is closing", detachWaiter1.error.message); + assertEquals("Error code should be CONNECTION_CLOSING(80001)", 80001, detachWaiter1.error.code);
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
lib/src/main/java/io/ably/lib/realtime/ChannelBase.java
(7 hunks)lib/src/test/java/io/ably/lib/test/realtime/RealtimeChannelTest.java
(9 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (10)
- GitHub Check: check (29)
- GitHub Check: check-rest
- GitHub Check: check (24)
- GitHub Check: check-realtime-okhttp
- GitHub Check: check (21)
- GitHub Check: check-rest-okhttp
- GitHub Check: check-realtime
- GitHub Check: build
- GitHub Check: check (19)
- GitHub Check: check
🔇 Additional comments (3)
lib/src/main/java/io/ably/lib/realtime/ChannelBase.java (3)
93-101
: LGTM! Well-structured error handling implementation.The implementation follows good practices with proper encapsulation and thread-safe error handling. The getter method appropriately clears the error after retrieval, which is good for one-time error handling.
1312-1318
: LGTM! Proper implementation of RTL13a spec requirement.The code correctly handles server-initiated detach for both attached and suspended states by:
- Storing the error from the detach message
- Attempting immediate reattachment
624-624
: LGTM! Proper error handling as per RTL5g.The implementation correctly propagates error information to the completion listener.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the latest changes look like workaround, I think we should avoid this
@@ -90,6 +90,16 @@ public abstract class ChannelBase extends EventEmitter<ChannelEvent, ChannelStat | |||
*/ | |||
private boolean released = false; | |||
|
|||
private ErrorInfo msgError; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it's a good idea to have this field in channel state just for one very specific use-case. I believe we should either refactor attach method so it will have optional error reason for attaching state, or if it's to complicated we should revert these changes and always send null
as error reason
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will try refactoring existing attachWithTimer
signature but it can affect it's usages across codebase.
If not possible, I will revert the change
@@ -90,6 +90,16 @@ public abstract class ChannelBase extends EventEmitter<ChannelEvent, ChannelStat | |||
*/ | |||
private boolean released = false; | |||
|
|||
private ErrorInfo msgError; | |||
|
|||
private ErrorInfo getMsgError() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method is misleading; it not only retrieves the message error but also removes it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, we can rename it since it's not a perfect getter
DETACHED
event #1051Summary by CodeRabbit
Summary by CodeRabbit
New Features
Bug Fixes
Refactor