Closed
Bug 1199231
Opened 10 years ago
Closed 9 years ago
Investigate non-gUM "unable to publish" exceptions on Desktop
Categories
(Hello (Loop) :: Client, defect, P3)
Hello (Loop)
Client
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: standard8, Assigned: standard8)
References
Details
(Whiteboard: [investigation][quality])
User Story
Done: - See if TokBox's data gives us more information - not particularly - Add more logging to desktop if appropriate - Some errors potentially caused by trying to start a window share but selecting no window - need to handle gUM failures better, bug 1210754. Todo: - Keep an eye out for any more failures, as the logging rolls out across the trees. - Investigate/fix/get fixed any issues found and improve reporting to users if appropriate.
Adam tells me that we're getting exceptions logged to the loop-server for TokBox's UNABLE_TO_PUBLISH exception from desktop only.
The strange things is, these don't appear to be directly related to getUserMedia failures, but something else.
Given that it seems like we're only seeing this from the link generator side currently, we should investigate what's happening.
Updated•10 years ago
|
Rank: 25
| Assignee | ||
Comment 1•10 years ago
|
||
Having investigated some of the data a bit more, there's a few possible conclusions:
- On 41, we are probably seeing a lot of effects of gUM failures due to not having bug 1193665. This is causing unnecessary 1500's that are being logged. These are raised before the room is joined, so only our servers see them and not TokBox's.
- If we look at 43 (which has bug 1193665), then there are still a few errors being raised.
We don't understand these so much at the moment, so we need to log the string alongside the exception, so that we can get the specific details of the error.
Note for follow-up: Possibly need to ask TokBox to simplify/refine error codes so that they aren't overloaded, or its easier to get the exact reason.
| Assignee | ||
Comment 2•10 years ago
|
||
Bug 1193665 is the incorrect reference. It should have been bug 1187309, which has landed for 42.
42 is also showing errors being raised still.
| Assignee | ||
Comment 3•10 years ago
|
||
Bug 1205610 has landed, so tagging to look at initial results in the next cycle.
Iteration: --- → 44.2 - Oct 19
| Assignee | ||
Updated•10 years ago
|
User Story: (updated)
Updated•10 years ago
|
Iteration: 44.2 - Oct 19 → ---
Updated•10 years ago
|
Status: NEW → ASSIGNED
| Assignee | ||
Comment 4•10 years ago
|
||
Bumping down the prio range a bit - I'm currently waiting on bug 1205610 to roll out a bit further before investigating this too much.
Rank: 25 → 30
Priority: P2 → P3
| Assignee | ||
Comment 5•9 years ago
|
||
Over time these the non-gUM ones have virtually gone away. Over the last couple of weeks we've only seen a handful.
I suspect a lot of this was about improving the logging as we went along, and I know there were various improvements around where/when we logged the gUM exceptions.
Therefore I'm closing this as WFM as there's nothing significant to investigate now.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•