Closed Bug 1611758 Opened 4 years ago Closed 4 years ago

OSX perma fail on Thunderbird - toolkit/components/telemetry/tests/unit/test_TelemetryController.js | xpcshell return code: 0

Categories

(Thunderbird :: General, defect, P5)

defect

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: intermittent-bug-filer, Unassigned)

Details

(Keywords: intermittent-failure)

Khushil tells me it's reproducible locally.

Assignee: nobody → khushil324

Could we have some action on this bug please?

Flags: needinfo?(khushil324)
Component: Add-Ons: General → General

Picking through the raw logs, I can see it's failing at this point:
https://searchfox.org/mozilla-central/source/toolkit/components/telemetry/tests/unit/test_TelemetryController.js#286

I think it's picking up a ping left over from the block of code directly above it, where it simulates a failed connection.

The TelemetryController.testReset() call a few lines earlier looks like it should just clobber any leftover pings and set us up in a pristine test state again... but still we receive a leftover deletion-request ping rather than the test-ping-type ping we were expecting.
I'm kind of stumped - I can't figure out why this is happening only on OSX, and why it doesn't seem to be an issue in m-c...

I think the thing to do is to start peppering the codebase with trace statements to pinpoint exactly what's happening (and maybe compare to Linux/windows). If all else fails I can try this, but without a mac I'd be resorting to submitting runs to the try server, which is a pretty excruciating way to debug code...

Sample log: https://firefoxci.taskcluster-artifacts.net/H-g7IBzIRiexEXmuUWTGrQ/0/public/logs/live_backing.log

task 2020-02-18T12:04:26.134Z] 12:04:26 WARNING - TEST-UNEXPECTED-FAIL | toolkit/components/telemetry/tests/unit/test_TelemetryController.js | test_disableDataUpload - [test_disableDataUpload : 83] The ping must have the correct type. - "deletion-request" == "test-ping-type"

Up until here it's ok: https://searchfox.org/mozilla-central/rev/0439db3a39faddb90197a87cc184c57dcbf0a770/toolkit/components/telemetry/tests/unit/test_TelemetryController.js#263

... but the deletion-ping left behind there is then received here
https://searchfox.org/mozilla-central/rev/0439db3a39faddb90197a87cc184c57dcbf0a770/toolkit/components/telemetry/tests/unit/test_TelemetryController.js#286

Should the Preferences.set be called before the PingServer.start() is called?
Where is the deletion-request ping supposed to go. Is it supposed to be cleared by the PingServer.start()?


Chris, any idea why this test isn't working on Thunderbird mac?

Flags: needinfo?(khushil324) → needinfo?(chutten)

Both pings should be sent, but the order appears to be backwards. As part of the send task we'll first send whatever pings have been submitted (in this case TEST_PING_TYPE), then any on the pending pings list (in this case "deletion-request"). This behaviour can be found here

I'm not sure what would make this platform-dependent and product-dependent. Let's look at the logs:

12:04:26.082 - test-ping-type is saved to disk because it couldn't be sent
12:04:26.085 - removes all pending pings (should include test-ping-type)
12:04:26.090 - deletion-request ping is saved to disk because it couldn't be sent
12:04:26.106 - feletion-request pending ping loaded after restart
12:04:26.126 - upload is re-enabled
12:04:26.126 - test-ping-type submitted
12:04:26.128 - pings to send: 1 current and 1 pending
12:04:26.130 - test-ping-type can't reach the PingServer <---- WAIT, What?
12:04:26.132 - deletion-request ping is successfully sent, failing the test

Well there's the problem: test-ping-type failed to be received, so it doesn't get you past line 286. So when the later deletion-request ping is received it fails the checks.

I'm not sure why it wasn't received. Maybe PingServer isn't started? Maybe the port is still closed? Do you have other theories?

Flags: needinfo?(chutten) → needinfo?(mkmelin+mozilla)
Flags: needinfo?(mkmelin+mozilla)

It is passing i.e PingServer.started is true when we reach there.

This disappeared.

Assignee: khushil324 → nobody
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME

It's showing up on c-esr78 on every release now: https://treeherder.mozilla.org/jobs?repo=comm-esr78&selectedTaskRun=EgmiY4CHQE2Z498hz3n4bw.0

Apparently something needs uplifting?

Status: RESOLVED → REOPENED
Flags: needinfo?(mkmelin+mozilla)
Resolution: WORKSFORME → ---

Seems OSX only, like it use to be.
We couldn't fix it earlier, so unlikely to be able to fix it now. But it should be just a test failure, so not too bad either. I guess we could disable that test for esr 78 if you don't want to see the yellow. r=mkmelin for that

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Flags: needinfo?(mkmelin+mozilla)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.