Last modified: 2013-12-05 01:26:53 UTC
Special:CategoryTree shows obviously cached results and there's no way how to purge it. examples: root (2 cats) +- a (2 cats) +- aa (10 pages) +- ab (20 pages) +- b (2 cats) +- ba (30 pages) +- bb (40 pages) Create category ac as subcat of a. Recategorize all bb to ac. The tree shows: root (2 cats) +- a (3 cats) +- aa (10 pages) +- ab (20 pages) +- ac (40 pages) +- b (2 cats) +- ba (30 pages) +- bb (40 pages) Delete the bb. The tree shows again: root (2 cats) +- a (3 cats) +- aa (10 pages) +- ab (20 pages) +- ac (40 pages) +- b (2 cats) +- ba (30 pages) +- bb (40 pages) Involved operations which are not reflected in the tree: * recategorizing of pages * deletion of category ** deleting when being empty ** deleting when not being empty, but then emptied * recategorizing of category * emptying the category (still shows the original number of content before emptying) The tree is being shown correct after about 48 hrs. ---- This behavior was not in past, so I'm adding code-update-regression keyword.
Another observation: Category tree shown: +- foo (5 pages) Two pages were taken out of foo category so the tree should show: +- foo (3 pages) but still shows +- foo (5 pages)
This is caused by the wmf config line: $wgCategoryTreeDisableCache = false; which is presumably to prevent category tree from killing server kittens. CategoryTree has no cache invalidating mechanisms (That I'm aware of) so if disabling parser cache is disabled, then it just caches it until it falls out of cache. I imagine this will be wontfixed. (Although maybe cat tree could be changed to shorten the duration of the cache). Anyhow, see
I disagree with Brian (Bawolff) slightly, The $wgCategoryTreeDisableCache might have implications I'm not aware of, but this bug is due to the caching in CategoryTree::ajax(), which creates and uses an instance of AjaxResponse. The CategoryTree::ajax() method doesn't do stringent enough testing for invalidation, it merely (hardcodes) the expiry as 86400 seconds (24 hours.) I understand the reasoning behind this -- to cache the responses of the ajax calls and make them fast/lightweight. However, when the category-structure changes, the ajax response doesn't get invalidated, leading to an error in the results.
(In reply to comment #3) > I disagree with Brian (Bawolff) slightly, > > The $wgCategoryTreeDisableCache might have implications I'm not aware of, but > this bug is due to the caching in CategoryTree::ajax(), which creates and uses > an instance of AjaxResponse. > > The CategoryTree::ajax() method doesn't do stringent enough testing for > invalidation, it merely (hardcodes) the expiry as 86400 seconds (24 hours.) I > understand the reasoning behind this -- to cache the responses of the ajax > calls and make them fast/lightweight. However, when the category-structure > changes, the ajax response doesn't get invalidated, leading to an error in the > results. Good catch. I didn't even know that CategoryTree::ajax did caching. If the inconsistency is in the initial state of the tree (before expanding anything), its probably the variable, otherwise it is likely what you suggest.
This problem is affecting us quite significantly, as most of our Grantmaking pages on Meta rely on CategoryTree to accurately represent the status of requests. This is causing needless anxiety to some applicants, and occasionally causes us to miss changes for 24 hours. Can this be considered an upvote or something, to get it fixed Real Soon Now<tm>?
(In reply to comment #5) > This problem is affecting us quite significantly, as most of our Grantmaking > pages on Meta rely on CategoryTree to accurately represent the status of > requests. This is causing needless anxiety to some applicants, and > occasionally causes us to miss changes for 24 hours. > > Can this be considered an upvote or something, to get it fixed Real Soon > Now<tm>? Don't take this the wrong way, but this is a low priority bug that would involve a lot of effort to fix properly, so probably not happening soon. At best you could maybe convince someone to decrease the cache time somewhat to say like 6 hours. Also most of the grant pages I've seen seem to use <DynamicPageList> not <categorytree>, are you sure you didn't mean that extension? (However both have the same issue)
Some sort of similar mechanism to manual cache invalidation as ?action=purge would be handy at least as a temporary solution. Then it would be possible to handle necessary important updates. Lowering the expiration time to 6 hrs would be also better than current state and since categorytree is not so widely used it should not harm server kittens too much. In a nutshell any simple workaround which would make it better than current state would be appreciated. No need to focus on complex sophisticated mechanisms (= postpone its development to far future), but immediate quick, maybe even dirty, hack.
