1216734 - when server returns HTTP 400, 202 "The room is full", standalone claims "first one here" and explodes

Status: RESOLVED WORKSFORME

(Hello (Loop) :: Client, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

Adam and I have been trying to debug something else.  I've been using Chrome Canary to connect to standalone in the production stack from a link generated by Adam.

If the server thinks the room is full, we see the following in the error console:

loop.services.mozilla.com/v0/rooms/hs6Y4t_oHj0:1 POST https://loop.services.mozilla.com/v0/rooms/hs6Y4t_oHj0 400 (Bad Request)

2015-10-20 13:22:21.857 VM877:175 Error in state `room-joining`: Error: HTTP 400 Bad Request
    at failureHandler (eval at <anonymous> (https://hello.firefox.com/js/standalone.js:1:448), <anonymous>:44:15)
    at Object.eval (eval at <anonymous> (https://hello.firefox.com/js/standalone.js:1:448), <anonymous>:142:11)
loop.store.ActiveRoomStore.loop.store.createStore.roomFailure @ VM877:175(anonymous function) @ VM873:75loop.Dispatcher.Dispatcher._dispatchNextAction @ VM873:73loop.Dispatcher.Dispatcher.dispatch @ VM873:47loop.store.createStore.baseStorePrototype.dispatchAction @ VM876:29(anonymous function) @ VM877:543callbackWrapper @ VM884:165failureHandler @ VM884:47(anonymous function) @ VM884:142

2015-10-20 13:22:21.864 VM873:77 [Dispatcher] Dispatching action caused an exception:  TypeError: c.stop is not a function(…)(anonymous function) @ VM873:77loop.Dispatcher.Dispatcher._dispatchNextAction @ VM873:73loop.Dispatcher.Dispatcher.dispatch @ VM873:47loop.store.createStore.baseStorePrototype.dispatchAction @ VM876:29(anonymous function) @ VM877:543callbackWrapper @ VM884:165failureHandler @ VM884:47(anonymous function) @ VM884:142

Presumably, this shouldn't be too hard to get better debugging output out of on a local deploy.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

In this case, the UI continues to blithely proclaim that "You're the first one here".

Comment 2

[Mark Banner (:standard8)]

I can't reproduce this. Using Chrome or Firefox gives me the expected room is full error on both production and development. 

However, I've just noticed I'm seeing:

'MediaStream.stop()' is deprecated and will be removed in M47, around November 2015. Please use 'MediaStream.active' instead.

So if you're seeing this on Chrome Canary, it sounds like they're already preparing to remove it.

Comment 3

[Mark Banner (:standard8)]

The exception is likely an issue in the sdk - I've just tested and upgrading to the latest sdk (2.6.7) in bug 1210865 doesn't fix the issue.

Michael - is there a fix in the works for this warning seen in comment 2?


I'm guessing the incorrect message is displayed because of the exception - the activeRoomStore doesn't get set to the failed state until after the disconnection has completed.

Comment 4

[Mark Banner (:standard8)]

(In reply to Mark Banner (:standard8) from comment #3)
> The exception is likely an issue in the sdk - I've just tested and upgrading
> to the latest sdk (2.6.7) in bug 1210865 doesn't fix the issue.
> 
> Michael - is there a fix in the works for this warning seen in comment 2?

This time I'll actually include the need info to Michael.

Comment 5

[msander]

I'm not sure about this one. I thought that would be fixed with the 2.6.7 sdk. Rolly can probably provide a better response.

Comment 6

[rolly]

We use MediaStream.stop or MediaStreamTrack.stop, depending on what is present in the browser. The warning is there because we check for MediaStream.stop first, and it is actually present in Chrome, so it gets used.

I'll make a fix in the newest develop and swaps those branches around so MediaStreamTrack.stop is preferred.

Michael: It will be a minor fix with minimal impact

Comment 7

[Ian Bicking (:ianbicking)]

Is this resolved?

Comment 8

[Ian Bicking (:ianbicking)]

Note: Dan hasn't seen this in a long time

Comment 9

[Mark Banner (:standard8)]

I've just tried this on chrome & chrome canary and can't repeat, so lets go with works for me.