1075654 - need to confirm loop client will reconnect to websocket upon server side termination

Status: VERIFIED FIXED

(Hello (Loop) :: Client, defect)

Description

[Edwin Wong [:edwong]]

tl;dr: can someone confirm that the client seamlessly reconnects the push websocket when disconnected from the server?

There's concern that killing Loop websocket connections from the server, when we update simplePush server and change DNS, requires that clients reconnect to the websocket in a seamless manner.  We're seeing this issue with FindMyDevice bug 1049693


STR:
1. push the Loop button and copy link
2. stop/start and change dns of push server
3. open link in new browser tab
4. click start call button in call.mozilla.com url

actual: the call does not ring desktop Fx

expected: it should or there should be an error and how to recover

Comment 1

[Mark Banner (:standard8)]

(In reply to Edwin Wong [:edwong] from comment #0)
> tl;dr: can someone confirm that the client seamlessly reconnects the push
> websocket when disconnected from the server?

http://hg.mozilla.org/mozilla-central/annotate/835ef55e175e/browser/components/loop/MozLoopPushHandler.jsm#l124

(Note: Please feel free to ask this sort of question in #loop where there's people around most of the day).

> STR:
> 1. push the Loop button and copy link
> 2. stop/start and change dns of push server
> 3. open link in new browser tab
> 4. click start call button in call.mozilla.com url
> 
> actual: the call does not ring desktop Fx
> 
> expected: it should or there should be an error and how to recover

In-between step 2 and 3, did you take account of dns propogation times etc?

Monitoring the Browser Console (not the web console), would be very useful for seeing the state of the push connection and if it is dropped/retried.

There is a back-off scheme:

http://hg.mozilla.org/mozilla-central/annotate/835ef55e175e/browser/components/loop/MozLoopPushHandler.jsm#l273

I think that's first time is either a minute or 5 minutes, then subsequent times is twice the previous delay.

Note, if the client hasn't detected the drop, then that might need bug 1028869.

Comment 2

[Mark Banner (:standard8)]

Edwin, please see comment 1.

Comment 3

[Edwin Wong [:edwong]]

Thanks :standard8 - we're deploying loop server soon so we'll see how clients respond.  closing

Comment 4

[u279076]

(In reply to Edwin Wong [:edwong] from comment #3)
> Thanks :standard8 - we're deploying loop server soon so we'll see how
> clients respond.  closing

Assuming this doesn't need further testing. Edwin, please advise if that's an incorrect assumption.

Comment 5

[Edwin Wong [:edwong]]

actually - we should test this when we bounce the servers, Richard could help you know when we're pushing new build to stage.

Comment 6

[u279076]

Richard, can you help out here? I can assist with client-side testing as needed.

Comment 7

[Richard Pappalardo [:rpapa][:rpappalardo]]

Hey Anthony - 
sure, other than letting you know when we're about to deploy to STAGE, what do you need from me?  Is the plan to generate a URL (on STAGE) just prior to a deploy and then verify if the user gets hung out to dry after the new STAGE deploy or does 'change dns of push server' involve any additional steps?

Comment 8

[u279076]

Richard, I think the plan is to be determined in the meeting today at noon. What I'll need from you remains to be determined but I will certainly need you to notify me when client testing can commence.

Comment 9

[u279076]

Taking QA Contact since I'll be the one doing the testing.

Comment 10

[Richard Pappalardo [:rpapa][:rpappalardo]]

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #8)
> Richard, I think the plan is to be determined in the meeting today at noon.
> What I'll need from you remains to be determined but I will certainly need
> you to notify me when client testing can commence.
np.  I'll add to the wiki: https://etherpad.mozilla.org/qa-sp-testing

Comment 11

[Richard Pappalardo [:rpapa][:rpappalardo]]

(In reply to Edwin Wong [:edwong] from comment #5)
> actually - we should test this when we bounce the servers, Richard could
> help you know when we're pushing new build to stage.

This has been verified with the loop-push update to 1.4.1 during the changeover from stage to prod
see: Bug 1104994