-
Notifications
You must be signed in to change notification settings - Fork 17
Fix re-subscription #602
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
Fix re-subscription #602
Conversation
Codecov Report
@@ Coverage Diff @@
## 7-dev #602 +/- ##
==========================================
+ Coverage 87.35% 87.39% +0.04%
==========================================
Files 33 33
Lines 1479 1476 -3
Branches 260 258 -2
==========================================
- Hits 1292 1290 -2
+ Misses 136 135 -1
Partials 51 51
Continue to review full report at Codecov.
|
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.
A couple nitpickings
src/Kuzzle.ts
Outdated
| const request = { ...req }; | ||
| const options = { ...opts }; |
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.
(nitpicking) or you could make a deep-copy, as it is safer in case users modify the referenced objects before they are submitted again, if they get queued
| const request = { ...req }; | |
| const options = { ...opts }; | |
| const request = JSON.parse(JSON.stringify(req)); | |
| const options = JSON.parse(JSON.stringify(opts)); |
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.
That's what I was doing at first but then I thought about the performance drop and I sticked to the light copy.
The query method is only mutating first level properties so IMHO it's enough and if users mutate there own payloads I think it's not our responsibility anymore
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.
About performances, I believe the JSON.stringify/JSON.parse method performs at roughly a couple millions instructions per second, so we should be quite safe there.
Co-authored-by: Sébastien Cottinet <scottinet@protonmail.com>
…pt into fix-resubscription
# [7.5.4](https://github.com/kuzzleio/sdk-javascript/releases/tag/7.5.4) (2021-02-17) #### Bug fixes - [ [#602](#602) ] Fix re-subscription on re-connection ([Aschen](https://github.com/Aschen)) #### Enhancements - [ [#586](#586) ] Add keep-alive mechanism to detect connection lost with realtime protocols ([Yoann-Abbes](https://github.com/Yoann-Abbes)) ---
What does this PR do?
When resubscribing after a
reconnectedevent, the SDK use the original subscriptionrequestto re-subscribe.The
Kuzzle.querymethod mutate request and inject the JWT inside. Meaning that the request saved for the re-subscription already has a JWT inside.This can be an issue because developers rely on the
kuzzle.jwtproperty of the SDK to know if 1) the token is still valid 2) there are connection information.Now the
requestandoptionsparameter of the query method are cloned before modification. (:warning: to save resources it's not a deep clone so only the top level properties are duplicated. Nested objects will not be cloned but only referenced)How should this be manually tested?
Run a Kuzzle stack and then create this user and update anonymous role:
Then run this script
resubscribe.js
Logs
Wait 2 sec and then stop Kuzzle:
Restart Kuzzle:
kourou realtime:publish test test '{ toto: 42 }' --username test-admin --password password)Other changes
checkTokenwhen the SDK reconnect because it breaks the workflow ontokenExpiredevents