Open
Bug 1819994
Opened 3 years ago
Updated 3 years ago
Log spew in telemetry XPCShell tests about failing to submit pings
Categories
(Toolkit :: Telemetry, task, P3)
Toolkit
Telemetry
Tracking
()
NEW
People
(Reporter: beth, Unassigned)
Details
These messages are repeated hundreds of times, which makes parsing logs difficult. Here is an example:
0:02.11 INFO "CONSOLE_MESSAGE: (error) [JavaScript Error: "1677783462848 Toolkit.Telemetry ERROR TelemetrySend::sendPersistedPings - failed to send ping 450c48c3-5e45-4896-b624-33cfff10e14f: SyntaxError: The URI is malformed. Stack trace: open()@resource://gre/modules/ServiceRequest.sys.mjs:133
_doPingRequest()@resource://gre/modules/TelemetrySend.sys.mjs:1313
_doPing()@resource://gre/modules/TelemetrySend.sys.mjs:1535
_sendPersistedPings/<()@resource://gre/modules/TelemetrySend.sys.mjs:1218
_do_main()@/home/barret/Workspace/src/hg.mozilla.org/mozilla-central/testing/xpcshell/head.js:240
_execute_test()@/home/barret/Workspace/src/hg.mozilla.org/mozilla-central/testing/xpcshell/head.js:585
-e:1" {file: "resource://gre/modules/Log.sys.mjs" line: 723}]
append@resource://gre/modules/Log.sys.mjs:723:12
log@resource://gre/modules/Log.sys.mjs:377:16
getLoggerWithMessagePrefix/proxy.log@resource://gre/modules/Log.sys.mjs:506:18
error@resource://gre/modules/Log.sys.mjs:385:10
_sendPersistedPings/<@resource://gre/modules/TelemetrySend.sys.mjs:1220:23
_do_main@/home/barret/Workspace/src/hg.mozilla.org/mozilla-central/testing/xpcshell/head.js:240:6
_execute_test@/home/barret/Workspace/src/hg.mozilla.org/mozilla-central/testing/xpcshell/head.js:585:5
I believe this is due to this line in user.js
Comment 1•3 years ago
|
||
Let's see, here... we could
- Provide a valid URI that uses e.g. example.com
- Tests will fail as soon as we try to make an external connection
- Provide a valid URI that is guaranteed to be loopback
- Might be fine, but there might be servers on port 80 on the local host, and no one needs to have to deal with that
- Catch and squelch the error in test mode (
this._testMode = true)- There may be tests that are specifically testing how we handle invalid URIs in that pref which will be upset if we squelch.
- Be clever, and make the test-mode-only squelching configurable
- Adds complexity, but not much, that would allow flexibility for all possible cases (including ones where we want to throw).
I think I'll start with #3 and if I find tests that rely on the failure move to #4.
Assignee: nobody → chutten
Severity: -- → N/A
Status: NEW → ASSIGNED
Priority: -- → P1
Comment 2•3 years ago
|
||
Ohhhhh goodness, approach #3 goes very wrong very quickly with some infinite looping. I'm gonna backlog this for a rainy day.
Assignee: chutten → nobody
Status: ASSIGNED → NEW
Priority: P1 → P3
You need to log in
before you can comment on or make changes to this bug.
Description
•