1065974 - Loop server doesn't inform the other party when a websocket is closed during connection

Status: VERIFIED FIXED

(Hello (Loop) :: Server, defect)

Description

[Mark Banner (:standard8)]

According to the original document on the websocket architecture:

====
https://wiki.mozilla.org/Loop/Architecture/MVP#WebSockets_Connection_for_Call_Progress

If the server sees the client close the connection, it assumes that the client has failed, and informs the other party of such call failure.
====

As far as I can tell, this isn't happening at the moment.

Comment 1

[Rémy Hubscher (:natim)]

During call setup there is three way that will raise a connection close:

 - supervisory timer
 - ringing timer
 - connection timer

Before closing the connection, an error will be sent also if the connection is closed one of this timer should send a terminate:timeout

Could you tell me the step to reproduce this please?

Comment 2

[Rémy Hubscher (:natim)]

I assume the three timeout defined above are sufficient to handle this case.

Comment 3

[Mark Banner (:standard8)]

Bug 1067591 is a perfect example of why we need this. Especially during the call ringing stage, but really during all stages - not notifying the clients, means that they could end up with multiple calls ongoing.

Additionally, if a caller's browser closed the tab (or crashed, etc) during the ringing phase, the callee could still try to answer and wonder why it didn't work.

Comment 4

[Rémy Hubscher (:natim)]

> Additionally, if a caller's browser closed the tab (or crashed, etc) during the ringing phase, the callee could still try to answer and wonder why it didn't work.

Then he will get the connectionTimeout.

Well let's try to add a on("close") event and see if it works.

Comment 5

[Mark Banner (:standard8)]

(In reply to Rémy Hubscher (:natim) from comment #4)
> > Additionally, if a caller's browser closed the tab (or crashed, etc) during the ringing phase, the callee could still try to answer and wonder why it didn't work.
> 
> Then he will get the connectionTimeout.

It could also be in the ringingTimer phase, which means it could be on the display for the best part of 30 seconds, plenty of time for another window to open as well (or get an incorrect "busy" signal).

(In reply to Rémy Hubscher (:natim) from comment #4)
> Well let's try to add a on("close") event and see if it works.

Ok, great.

Comment 6

[Rémy Hubscher (:natim)]

Attachment: Link to Github PR — #210

Comment 7

[Alexis Metaireau (:alexis)]

Comment on attachment 8490786 [details] [review]
Link to Github PR — #210

https://github.com/mozilla-services/loop-server/commit/aa50ebf4be89813a7f4aedceac0688b1ffe987b7

Comment 8

[Alexis Metaireau (:alexis)]

Waiting on Standard8 feedback before closing but we're good to go IMO.

Comment 9

[Mark Banner (:standard8)]

Comment on attachment 8490786 [details] [review]
Link to Github PR — #210

Yes, this looks fine. Thanks. I think the "close" probably needs adding to the documentation.

Comment 10

[Rémy Hubscher (:natim)]

Documentation updated here: https://github.com/mozilla-services/docs/commit/18f76b64e98807312fc45328dc4521b4d1e5cedd

Comment 11

[Rémy Hubscher (:natim)]

https://github.com/mozilla-services/loop-server/commit/aa50ebf4be89813a7f4aedceac0688b1ffe987b7

Comment 12

[James Bonacci [:jbonacci]]

This went out with 0.12.2.