Closed Bug 1315829 Opened 4 years ago Closed 2 years ago

Intermittent TEST-UNEXPECTED-TIMEOUT | toolkit/components/extensions/test/xpcshell/test_ext_runtime_onInstalled_and_onStartup.js | Test timed out

Categories

(WebExtensions :: General, defect, P2)

defect

Tracking

(firefox66 fixed)

RESOLVED FIXED
mozilla66
Tracking Status
firefox66 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: robwu)

References

(Blocks 2 open bugs)

Details

(Keywords: intermittent-failure, Whiteboard: [stockwell fixed])

Attachments

(1 file)

Component: WebExtensions: Untriaged → WebExtensions: General
Priority: -- → P3
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Matt, for some reason, on Linux this is failing frequently on my 57-as-Beta uplift simulation pushes on Try.

https://treeherder.mozilla.org/logviewer.html#?job_id=127929458&repo=try

https://hg.mozilla.org/try/rev/284abec94b69683bf6918f36818adfff96bdb066 applied locally should suffice for reproducing the specific build configuration. Is there any chance you could take a look?
Flags: needinfo?(matthewjwein)
Matt is no longer working for Mozilla, I'll try to take a look today.
Flags: needinfo?(matthewjwein) → needinfo?(aswan)
I'm pretty certain that this is a test issue and not a product regression.  I looked at several logs and they are timing out in a bunch of different places, but all the ones that I looked at appeared to be at `await extension.awaitStartup()` calls following an extension or AddonManager restart.  Our extension wrappers track restarts by tracking a sequence of events that come from both the AddonManager and the webextension framework.  There's not necessarily a forced ordering between some of these events (eg between an extension Management ready or startup event and the corresponding AddonManager onInstalling and onInstalled events).  I suspect there's some sequence that causes the extension wrapper startup promise to not get properly set up.

I was also unable to reproduce this in a local run (though I didn't do all that many test runs).  Anyway, I think this should be fixable with some modest effort, but since it appears to just be a test issue, I think that work can be safely deferred until after we're done with pressing 57 work.
Flags: needinfo?(aswan)
FWIW, I intend to skip this test on Linux once 57 hits Beta because it's essentially permafailing on my uplift simulations in any regard. Not saying I disagree with the prioritization, but FYI.
There are lots of try failures here, but even with those excluded, this is quite frequent. Given comment 15 (thanks :aswan), I think I'll skip this.
Flags: needinfo?(gbrown)
Whiteboard: [stockwell needswork]
Pushed by gbrown@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/e217f827cc16
Skip xpcshell test_ext_runtime_onInstalled_and_onStartup.js for frequent intermittent failures; r=me,test-only
Flags: needinfo?(gbrown)
Keywords: leave-open
Whiteboard: [stockwell needswork] → [stockwell disabled]
Bulk priority update of open intermittent test failure bugs. 

P3 => P5

https://bugzilla.mozilla.org/show_bug.cgi?id=1381960
Priority: P3 → P5
This is skipped on all platforms, so should be treated as a high priority to re-enable. I'm going to make it a P2.
Priority: P5 → P2
Product: Toolkit → WebExtensions

I'm going to fix the test. The declarativeContent API (bug 1435864) is supposed to be called from the runtime.onInstalled event, and lack of test coverage for runtime.onInstalled may result in unwanted regressions.

Assignee: nobody → rob
Blocks: 1435864
Status: REOPENED → ASSIGNED
Pushed by rob@robwu.nl:
https://hg.mozilla.org/integration/autoland/rev/c301f8a7914c
Re-enable test_ext_runtime_onInstalled_and_onStartup.js r=aswan
Keywords: leave-open
Status: ASSIGNED → RESOLVED
Closed: 3 years ago2 years ago
Resolution: --- → FIXED
Whiteboard: [stockwell disabled] → [stockwell fixed]
Target Milestone: --- → mozilla66

Will QA validation be required for this bug?

Flags: needinfo?(rob)
Flags: needinfo?(rob) → qe-verify-
You need to log in before you can comment on or make changes to this bug.