-
Notifications
You must be signed in to change notification settings - Fork 16
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
Manual testing on RTN14 and RTN15 #27
Conversation
9178040
to
9949795
Compare
5f5a8cb
to
0a85c32
Compare
9949795
to
c727e99
Compare
0a85c32
to
4af537a
Compare
59ff55b
to
176d8c1
Compare
c61e063
to
5565a5f
Compare
after testing for Connection Failure and Connection Resume spec
d992307
to
34db0d2
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.
Minor comment. Happy for you to resolve, or leave as is, as you see fit.
ManualTesting.md
Outdated
and feasible tests can be converted to automated tests. | ||
|
||
This document currently targets **RTN14** and **RTN15** | ||
sections of the [spec](https://docs.ably.io/client-lib-development-guide/features/#idl), partially |
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.
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.
Done: 5c9c04e
@QuintinWillison I'd like to merge this and discuss on the results later as they are already added to ManualTesting.md |
This PR aims to acknowledge RTN14 and RTN15 are complied with in this package, however, few points are skipped considering nascent stage of this package.
RTN14a ✅
Actions done
connectionStateChange
listeners andchannelStateChange
listenersrealtime.connect()
RTN14b, RTN14g ⛔
Ignoring as these spec items for now as they revolve around
ProtocolMessage
RTN14c, RTN14d, RTN14e, RTN14f ✅
Turning wifi off - reconnect triggers every 15 seconds
loops between states:
connecting
anddisconnected
every 15s for 60s (i.e., until the defaultconnectionStateTtl
)there-further, state changes between
connecting
andsuspended
continuously.RTN15h, RTN15h1, RTN15h2 ✅
Temporary key ✅
Created a temporary key on web console and deleted that after connection is established.
Connection disconnected, and eventually status changed to failed after 1 retry.
Temporary app ✅
Created a temporary app on web console and deleted that after connection is established.
Connection disconnected, and eventually status changed to failed after 1 retry.
Restricted API key ✅
Trying to attach to a channel with an API key with restricted access
Un-restricting the above API Key, and manually re-connecting ❓
The above, with updated API key settings to remove restrictions and trying a fresh connection again by
realtime.connect()
on same realtime instance:ConnectionState
changes toconnected
but with a reason "Connection Unavailable" ❓This sounds and feels fishy 🎣
If a fresh realtime instance is used to connect, it connects as expected.
Another observation ❗
If a channel is already connected, it can publish and subscribe to/from that channel even if API Key settings are updated with new restricted permissions. This feels a bit concerning to me, but could be technically costly.
RTN15a ❓
Token has expired => not sure how to create this scenario
RTN15g (RTN15g1, RTN15g2, RTN15g3) ✅
These items are closely related with logs shared under heading
RTN14c, RTN14d, RTN14e, RTN14f
aboveRTN15i, RTN15b (RTN15b1, RTN15b2), RTN15c (RTN15c1, RTN15c2, RTN15c3, RTN15c4), RTN15e ⛔
Ignoring as these spec items for now as they revolve around
ProtocolMessage
RTN15f ⛔
Ignoring as these spec items for now as they revolve around
ACK
andNACK
RTN15d ⛔
Integration Tests - unsure of the priority on integration tests at the moment.
TL;DR ⌚ 🏃♂️
Temporary connection issues ✅
Cause:
What's happening:
disconnected
state untilconnectionStateTtl
is reachedconnectionStateTtl
is reached, connection goes intosuspended
state while connection re-establishment happens in background.Permanent connection issues ✅
Cause:
What's happening?
ConnectionState
changes in the following order and halts:connecting
->connected
->disconnected
->connecting
->failed
Connection succeeds initially, and when attaching to a channel that is restricted with the API key, it fails with code
40160
andChannelState
changes tosuspended
whileConnectionState
still staysconnected
Additional Scenario: ❓
Un-restricting the restricted API Key - Connection on already available Realtime instance would not work. It requires us to use a fresh Realtime instance to be able to operate normally again.