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)

task

Tracking

()

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

https://searchfox.org/mozilla-central/rev/a94fc6d9ececbf64a995d7ce9dc6eba0ffad7b67/testing/profiles/xpcshell/user.js#20

Let's see, here... we could

  1. Provide a valid URI that uses e.g. example.com
    • Tests will fail as soon as we try to make an external connection
  2. 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
  3. 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.
  4. 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

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.