Server sends an unexpected(?) websocket event 60 seconds after accept, with a "null" state

RESOLVED FIXED

Status

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: standard8, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa?])

(Reporter)

Description

4 years ago
STR:

1) Create two websocket connections to the server (one for desktop, the other standalone)
2) Send appropriate "hello" messages from both ends
3) Send "{ messageType: "action", event: "accept" }"

=> This is correctly received at both ends "{"messageType":"progress","state":"connecting"}"

4) Wait 60 seconds, server sends:

"{"messageType":"progress","state":"null"}"

The spec doesn't allow for a state of "null".

http://docs.services.mozilla.com/loop/apis.html#call-progress-state-change-progress
Whiteboard: [qa?]
That's correct. Remy updated the dev server with a fix that's part of 0.11, can you try again there and confirm it happens again?
Flags: needinfo?(standard8)
(Reporter)

Comment 2

4 years ago
(In reply to Alexis Metaireau (:alexis) from comment #1)
> That's correct. Remy updated the dev server with a fix that's part of 0.11,
> can you try again there and confirm it happens again?

I was using head of loop-server, and there have been no updates since I reported this.
Flags: needinfo?(standard8)
I wrote some tests and I'm not able to reproduce this with the test suite. (code is at https://github.com/mozilla-services/loop-server/compare/bug1059734/ws-null-state?expand=1, if can double check I'm doing the right checks?)

Can you provide me with another way to reproduce this?
Should have been fixed by https://github.com/mozilla-services/loop-server/commit/f074d57735b415b7642d702364fa7a46feae9089
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.