1188917 - Hello can get in an unresponsive state

Status: RESOLVED INCOMPLETE

(Hello (Loop) :: Client, defect, P3)

Description

[Adam Roach [:abr]]

We've had a report of Hello getting into a state where it refused to display a user's list of rooms (the user was not logged in to FxA). Attempts to create rooms also failed.

Throughout this series of failures, the console log showed no errors. No failure dialogs were displayed to the user.

The problem resolved on browser restart.

As a first step for approaching this bug, I would propose that we add detailed instrumentation to log success and failure steps when retrieving a user's list of rooms. To determine the potential impact of this issue, we should subsequently make sure that any detected errors are sent to the network (e.g., logged to the loop server or telemetry).

Comment 1

[Mark Banner (:standard8)]

I'd like to propose that the alternative first step, or early step is also to implement UX around what happens when the server is down.

Currently, we have two failure points:

- No connection to push server
- No connection to loop server

The first of these is currently most severe on start-up - if we can't get a link to the push server, then we implement a back-off algorithm. Until that succeeds, we won't register with the loop server (iirc, it can't as the push server is a required param).

If the loop-server is unavailable on startup, we'll hit the same issue with the push servers - because we won't be able to get the push server url.

If the loop-server is available on startup, but we loose the ability to talk to it later, we display "something went wrong" when the user tries to do things.

With the push server being down, the user just won't know about it.

So in both of the startup cases, and one of the already-running cases, we're displaying zero UX to the user, which is why I think we should prioritise that slightly over the logging of how much we're hitting.

I would reference the bug but I can't find it at the moment.

Comment 2

[:shell escalante]

need to break down into smaller bug components across different areas.  one being instrumentation.

Comment 3

[Mark Banner (:standard8)]

Starting to break this down a bit:

- Bug 1194622 has implemented a loading indication, this should at least let users know that there's something up.
- Bug 1203138 for giving the user an indication that the connection is down.

Adam: for reporting, I think we should use telemetry - if there's network issues, then its more likely that it'll get reported via telemetry that it happened. However, I'm also a bit concerned whether or not we can report this well enough to avoid issues like the computer going to sleep and killing the connection (which would confuse the data).

Thoughts?

Comment 4

[Adam Roach [:abr]]

The issue with telemetry -- at least using the normal interface -- is that we're not going to get a coherent log like we do with the loop server.

We can define a different record type, like we do with ICE failure reports, it fixes that issue; however, we need someone to write the analysis job for it if we go that way. It's also going to require additional scrutiny from the data stewards, since it's a new kind of data collection rather than incremental tweaks to an existing data collection service.

Comment 5

[Mark Banner (:standard8)]

FYI, I think bug 1207300 should have fixed the main cause for this. Bug 1210501 is tracking ongoing work to improve the UX. We can leave this one open to decide on what other logging we want to end up with.

Comment 6

[Mark Banner (:standard8)]

Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.