2/26 AMO blocklist update broke mozilla-central



8 years ago
4 years ago


(Reporter: khuey, Assigned: fox2mike)




+++ This bug was initially created as a clone of Bug #635044 +++

tl;dr please reverse the SQL run in Bug 636254 because it's breaking the tree.

The changes requested in Bug 635044 and run in Bug 636254 were picked up by some sort of automation system and pushed into our hg repos at which point they promptly broke xpcshell tests on all platforms.

There are likely a number of underlying issues here (faulty tests, releng's automation being DONTBUILD, us not running tests on blocklist updates, etc) but the quickest path to victory here is to undo the changes from Bug 636254.
We spent a bunch of time figuring out what was happening due to the silent update.
- automated blocklists upodates should not be DONTBUILD
- add-ons manager tests are not ready to accept these updates
- there is no indication in the automated update message of who is responsible for it (so it's even hard to just figure out who to ping in case of problems) and which bug did the change
Also, please avoid these automated updates on days where nobody is around like end of friday/saturday.

Comment 3

8 years ago
Alright, lemme look at this.
Assignee: server-ops → shyam

Comment 4

8 years ago
Releng - this was your automated commit hence CC'ing you all.


8 years ago
Summary: 2/26 AM blocklist update broke mozilla-central → 2/26 AMO blocklist update broke mozilla-central

Comment 5

8 years ago
(In reply to comment #0)
> tl;dr please reverse the SQL run in Bug 636254 because it's breaking the tree.

This has been reverted. Leaving the bug open to make sure the tests pass again.

Comment 6

8 years ago
(In reply to comment #4)
> Releng - this was your automated commit hence CC'ing you all.

Forgot to mention that the URL in this bug has the commit details.
Tests are passing again.
Last Resolved: 8 years ago
Resolution: --- → FIXED
What tests were failing, can we get logs?
TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/test_bug619730.js | null == GFX - See following stack:
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/head.js :: do_throw :: line 439
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/head.js :: do_check_eq :: line 491
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/test_bug619730.js :: <TOP_LEVEL> :: line 33
JS frame :: resource://gre/components/nsBlocklistService.js :: <TOP_LEVEL> :: line 606
JS frame :: resource://gre/components/nsBlocklistService.js :: <TOP_LEVEL> :: line 554
JS frame :: resource://gre/components/nsBlocklistService.js :: <TOP_LEVEL> :: line 483
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/test_bug619730.js :: load_blocklist :: line 14
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/tests/toolkit/mozapps/extensions/test/xpcshell/test_bug619730.js :: run_test :: line 52
JS frame :: /home/cltbld/talos-slave/test/build/xpcshell/head.js :: _execute_test :: line 322
JS frame :: -e :: <TOP_LEVEL> :: line 1

Mossop, I thought that test would only ever load the blocklist specified, but it seems like it's also loading the checked-in blocklist xml file...
Yeah I can see the issue. The problem is here: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/nsBlocklistService.js#525

In order to tell what add-ons have been newly blocked we load the old list first to compare it to the new. This has the side effect of notifying about the GFX entries.

You could fix this by creating an empty blocklist.xml file in the profile directory before starting the load.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.