-
Notifications
You must be signed in to change notification settings - Fork 25
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
Detach fails with timeout #1932
Comments
Turned out |
@maratal i just tested this quickly, it seems that if you create a realtime connection and just send a |
If I call Summary: if the channel is You can quickly check it in "test__105__Connection__Transport_disconnected_side_effects__should_resent_the_DETACH_message_if_there_are_any_pending_channels" test by unskipping it (I would comment |
"test__063__Channel__detach__happens_when_channel_is_ATTACHED_if_connection_is_currently__DISCONNECTED" fails sometimes with "
Attached
is not equal toAttaching
", since it asserts channel to be in theAttaching
state before the call todetach
. But it claims in the name that the state should beAttached
. If you wait for the channel to attach first, then this test will fail,because RTL5h and RTL4i implementation clash - once disconnected, call towith timeout.detach
will fall into a queue leading the channel to be detached onceCONNECTED
(sending queued messages), but at the same time the realtime explicitly will callattach
onceCONNECTED
leading two messages (Attach
andDetach
) sent to the server leading thedetach
call failAlso happens in "test__105__Connection__Transport_disconnected_side_effects__should_resent_the_DETACH_message_if_there_are_any_pending_channels" which is why it was skipped I guess.
┆Issue is synchronized with this Jira Task by Unito
The text was updated successfully, but these errors were encountered: