-
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
Proper RSH8b and RSH3g2a behavior. #1847
Conversation
…n activate) and initialising `clientId` at the same moment (RSH8b). Device's `id` and `secret` no longer are being generated lazily on the first call (RSH8a). I didn't touch any threading code here on purpose, since this PR is already complex enough.
Many tests relied on device details were there by default, so the only way to supply the details there (without proper state machine activation sequence) is to artificially call the `setupLocalDevice()`.
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.
LGTM
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.
Do the tests not need updating (or new ones adding) for the new behaviours that you've implemented? There are existing tests that claim to test RSH8b and RSH3g2a but presumably they're inadequate given that those spec points weren't implemented.
6c6f0fb
to
9277ab0
Compare
9277ab0
to
12521f8
Compare
…e deviceSecret (due to wrong spec PCD2 which draws id as not nullable).
f934274
to
7159d42
Compare
7159d42
to
1873d81
Compare
Co-authored-by: Lawrence Forooghian <[email protected]>
…y/ably-cocoa#1847, where a new device ID is generated as soon as the previous ones are cleared, so that id is never null.
…y/ably-cocoa#1847, where a new device ID is generated as soon as the previous ones are cleared, so that id is never null.
See #1842, #1253 and commit messages for context.