Opened on 10/28/2014 at 02:46:52 PM

Last modified on 12/21/2017 at 11:28:41 AM

#1501 new defect

Filter lists are not always downloaded and are not re-downloaded.

Reported by: sergz Assignee:
Priority: Unknown Milestone:
Module: Libadblockplus Keywords:
Cc: fhd, mapx Blocked By:
Blocking: Platform: Unknown
Ready: no Confidential: no
Tester: Verified working: no
Review URL(s):



The revision from which libadblockplus is built is 4872480b63c3 (the latest currently). I observe it in abpshell as well as in IE plugin.

How to reproduce

It's not easy to reproduce but when it happens it's very annoying. So, for now there are no concrete steps.
To reproduce the re-downloading trouble:

  • disable internet connection
  • launch abpshell
  • exit from abpshell
  • enable internet connection
  • launch abpshell
  • try to match some known url

Observed behaviour

It does not match any rule and filters are not downloaded.
The content of patterns.ini is

  • from abpshell
    # Adblock Plus preferences
  • from IE (exception rules are not downloaded)
    # Adblock Plus preferences
    [Subscription filters]
    ! Last modified: 28 Oct 2014 10:40 UTC
    ! *** easylist:easylist_adult/adult_whitelist_popup.txt ***

Expected behaviour

If filter list is not completely downloaded it should download filter list again and match should report that information is not available instead of "No match".

Attachments (0)

Change History (5)

comment:1 Changed on 10/28/2014 at 03:26:19 PM by mapx

  • Cc mapx added

comment:2 Changed on 10/28/2014 at 03:57:59 PM by trev

The retry interval after a download failure is one day - your abpshell won't redownload immediately, that's by design. The reason is: if the download failure is due to our servers really being unreachable, then as soon as they are online again they will be bombarded with requests. Everybody who didn't manage to reach the servers during the downtime will immediately try to redownload, causing a massive traffic spike and likely overloading the servers. We've had this situation before, and we definitely don't want to deal with it again.

The specific scenario where there is no internet connection should be addressed by #271 (would need to propagate up to MSIE of course).

So from what I can tell, this issue should be resolved as "rejected."

comment:3 Changed on 10/28/2014 at 04:17:52 PM by sergz

One day delay is clear. But it should not behave like the everything is OK. When we test whether some request matches the filter entry the result should also contain the information about broken subscriptions or at least there should be a way to query subscription status.

comment:4 Changed on 10/29/2014 at 05:21:30 AM by fhd

Yeah, I can see what you mean. How I see it, we have two sorts of error here:

  1. A subscription download failed.
  2. There are no filters at all. (Probably mostly caused by subscription downloads failing, but could also be the user removing all subscriptions.)

IMO, neither of this is always a problem and something we should warn the user about. But in combination, it's most definitely a problem worth mentioning.

So, when a subscription download fails, we could have code that checks if the subscription was ever downloaded successfully, and if not (and maybe if it's more than, say, 14 days old), invokes some callback clients can react to.

Seems like something we should have in Core actually - I don't think we tackle this particular problem on any platform so far.

comment:5 Changed on 12/21/2017 at 11:28:41 AM by fhd

  • Cc trev removed

Add Comment

Modify Ticket

Change Properties
as new .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from (none).
Next status will be 'reviewing'.
Note: See TracTickets for help on using tickets.