47 bytes, text/x-phabricator-request
|Details | Review|
Component: WebExtensions: Untriaged → WebExtensions: General
Priority: -- → P3
2 years ago
Status: NEW → RESOLVED
Closed: 2 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?
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.
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.
Whiteboard: [stockwell needswork]
Pushed by email@example.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
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
Assignee: nobody → rob
Status: REOPENED → ASSIGNED
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/c301f8a7914c Re-enable test_ext_runtime_onInstalled_and_onStartup.js r=aswan
Depends on: 1522873
No longer depends on: 1522873
Status: ASSIGNED → RESOLVED
Closed: 2 years ago → 5 months ago
Resolution: --- → FIXED
Whiteboard: [stockwell disabled] → [stockwell fixed]
You need to log in before you can comment on or make changes to this bug.