Closed
Bug 1038675
Opened 10 years ago
Closed 10 years ago
expiresAt parameter of /call-url/ response has changed from hours to seconds (Loop desktop client doesn't register on startup of browser)
Categories
(Hello (Loop) :: Client, defect, P1)
Hello (Loop)
Client
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla33
People
(Reporter: standard8, Assigned: standard8)
References
Details
(Keywords: regression, Whiteboard: [p=1])
Attachments
(1 file)
The current production server is returning hours for the "expiresAt" parameter, whereas the latest version on master is now returning seconds.
This is causing a regression in the client for it to not register on startup.
This is because we take the expiresAt and multiply it up into seconds, but it gets truncated at 32 bits.
AFAIK this wasn't a planned change.
Assignee | ||
Comment 1•10 years ago
|
||
A solution to this should block a 0.9.0 server release, as otherwise people might not receive incoming calls as their client doesn't think it is necessary to register.
Blocks: 1024222
Comment 2•10 years ago
|
||
I think it was a mistake to have it in hours. Unix timestamp are a standard and we tried to make sure all expiration date where timestamp for MVP.
Assignee | ||
Comment 3•10 years ago
|
||
We're going to fix this on the client, and it'll be likely it might break things on nightly for a few days until the server is fixed up, but for most people that shouldn't be too bad.
Assignee: nobody → standard8
Component: Server → Client
Assignee | ||
Updated•10 years ago
|
Whiteboard: [p=1]
Updated•10 years ago
|
Whiteboard: [p=1] → [p=1] [qa?]
Assignee | ||
Comment 4•10 years ago
|
||
This does the necessary changes to make registration work on startup with the latest server. We were seeing this worse with the new server, because the way the code works, the javascript was able to cope with 64-bit ints, so it was taking the seconds, multiplying it up (now unnecessarily), and seeing that it was greater than the existing time, however, the preference saving code only saves it as 32-bits. Hence, getting the wrong time.
We can't do anything about the pref code, but really if the values are consistent this isn't a problem anyway.
When we land this, there will be a period of time (until the server gets updated), where people who haven't used Loop before are not going to be automatically registering on startup, and hence won't be able to receive calls until they open the panel. Hopefully at the moment most folks are generating a link & using it straight away, but we can post in the newsgroup so that people are aware.
For those that already have used links, they'll be fine, because we won't be dealing with overflows, and so the code to check if the new expiry time is later than the existing one will work correctly, and won't update the pref - so they'll be registering for 30 days anyway.
Attachment #8456729 -
Flags: review?(nperriault)
Comment on attachment 8456729 [details] [diff] [review]
expiresAt parameter of /call-url/ response has changed from hours to seconds with the latest server version (Loop desktop client doesn't register on startup of browser).
Review of attachment 8456729 [details] [diff] [review]:
-----------------------------------------------------------------
LGTM
Attachment #8456729 -
Flags: review?(nperriault) → review+
Assignee | ||
Comment 6•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/79a9cefa3538
Will post to dev-media before the nightlies are released.
Priority: -- → P1
Target Milestone: --- → mozilla33
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Mark, can you please confirm if this needs manual testing?
Flags: qe-verify?
Flags: needinfo?(standard8)
Whiteboard: [p=1] [qa?] → [p=1]
Assignee | ||
Comment 9•10 years ago
|
||
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #8)
> Mark, can you please confirm if this needs manual testing?
I don't think we need extra manual testing for this. This is generally tested with the panel tests.
Flags: needinfo?(standard8)
You need to log in
before you can comment on or make changes to this bug.
Description
•