Closed Bug 637008 Opened 9 years ago Closed 9 years ago

2/26 AMO blocklist update broke mozilla-central


( Graveyard :: Server Operations, task, blocker)

Not set


(Not tracked)



(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.
Alright, lemme look at this.
Assignee: server-ops → shyam
Releng - this was your automated commit hence CC'ing you all.
Summary: 2/26 AM blocklist update broke mozilla-central → 2/26 AMO blocklist update broke mozilla-central
(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.
(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.
Closed: 9 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:

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: → Graveyard
You need to log in before you can comment on or make changes to this bug.