Last modified: 2014-11-20 03:32:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T51803, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 49803 - Calculated Age of persons can become outdated until next cache purge
Calculated Age of persons can become outdated until next cache purge
Status: UNCONFIRMED
Product: MediaWiki
Classification: Unclassified
General/Unknown (Other open bugs)
1.22.0
All All
: Low trivial (vote)
: ---
Assigned To: Nobody - You can work on this!
:
: 51128 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-19 10:03 UTC by Alex
Modified: 2014-11-20 03:32 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Alex 2013-06-19 10:03:34 UTC
Pages about persons where age is calculated automatically are saved in the cache until the next cache purge or the page change happens. Calculated value of the age is also saved.

After the date of birth of a person passes the saved age does not change.

Example: Paul McCartney has birthday on 18.06.1942. His wiki page was edited before 18.06.2013 and his age of 70 was saved in cache (which is correct). Then after 18.06.2013 no one changed his page or invalidated cache, that's why his age was 70 while it had to be 71 (which is not correct).

Notes: This can happen for all pages with calculated age. Possible, other calculated fields are also affected.

Possible solution: invalidate cache on some conditions met. For example, invalidate the cache of Paul McCartney's page on 18.06 of every year by settings Expires header.
Comment 1 Alex Monk 2013-06-19 14:02:16 UTC
Age calculations are done in wikitext, and generally the software does not do anything different based on such things. It does not see individual pieces of information displayed in an infobox, but just plain text.
Comment 2 Alex 2013-06-19 14:06:10 UTC
Is that possible to specify caching settings for the page during its generation based on the expressions in wikitext?
Comment 3 Andre Klapper 2013-07-11 08:54:18 UTC
*** Bug 51128 has been marked as a duplicate of this bug. ***
Comment 4 Bartosz Dziewoński 2013-07-11 16:43:32 UTC
Core time-related magic variables already set parser cache TTL to one hour or one day (depending on the variable). So either this is a problem in an extension (ParserFunctions? Scribunto?), or Wikimedia wikis do something wrong.
Comment 5 Gerrit Notification Bot 2013-07-11 17:02:32 UTC
Change 73188 had a related patch set uploaded by Brian Wolff:
Make {{#time:...}} expire parser cache after 12 hours.

https://gerrit.wikimedia.org/r/73188
Comment 6 Bawolff (Brian Wolff) 2013-07-11 17:05:40 UTC
I would note here for reference that this expiry wont affect squid/varnish cache (what the anons see), but usually that's not that big a deal.
Comment 7 Bawolff (Brian Wolff) 2013-07-12 22:46:10 UTC
(In reply to comment #0)
> Pages about persons where age is calculated automatically are saved in the
> cache until the next cache purge or the page change happens. Calculated value
> of the age is also saved.
> 
> After the date of birth of a person passes the saved age does not change.
> 
> Example: Paul McCartney has birthday on 18.06.1942. His wiki page was edited
> before 18.06.2013 and his age of 70 was saved in cache (which is correct).
> Then
> after 18.06.2013 no one changed his page or invalidated cache, that's why his
> age was 70 while it had to be 71 (which is not correct).
> 
> Notes: This can happen for all pages with calculated age. Possible, other
> calculated fields are also affected.
> 
> Possible solution: invalidate cache on some conditions met. For example,
> invalidate the cache of Paul McCartney's page on 18.06 of every year by
> settings Expires header.

Hmm, I just looked at the wiki. {{Age}} uses {{CURRENTDAY}} to calculate the person's age, which means the page should have been rechecked once an hour...
Comment 8 Gabriel Wicke 2013-07-12 22:53:23 UTC
The docs suggest that CURRENTDAY returns UTC, so the timeout can be between 0 and 24 hours.
Comment 9 Gerrit Notification Bot 2013-08-07 20:35:41 UTC
Change 73188 abandoned by Brian Wolff:
Make {{#time:...}} expire parser cache after 12 hours.

https://gerrit.wikimedia.org/r/73188
Comment 10 Derk-Jan Hartman 2014-04-29 15:01:57 UTC
I saw another report of this problem recently on VP/T. A user was complaining that he often had to do manual purges of these kinds of pages, because users on OTRS or helpdesk were reporting incorrect ages in google etc.

(so because there is no varnish purge). So perhaps we do need a bit of improvement here....
Comment 11 Gabriel Wicke 2014-05-28 23:45:51 UTC
Jackmcbarn created a very related patch at https://gerrit.wikimedia.org/r/#/c/135887/ . It adds the ability to set a TTL per transclusion, which is then exposed through the API.
Comment 12 Gerrit Notification Bot 2014-05-29 01:06:44 UTC
Change 135887 had a related patch set uploaded by Jackmcbarn:
Add PPFrame::getTTL() and setTTL()

https://gerrit.wikimedia.org/r/135887
Comment 13 Gerrit Notification Bot 2014-06-09 20:46:38 UTC
Change 135887 merged by jenkins-bot:
Add PPFrame::getTTL() and setTTL()

https://gerrit.wikimedia.org/r/135887
Comment 15 Andre Klapper 2014-09-01 12:42:58 UTC
(In reply to Gabriel Wicke from comment #14)
> Also related: https://gerrit.wikimedia.org/r/#/c/136617/,
> https://gerrit.wikimedia.org/r/#/c/136618/ and
> https://gerrit.wikimedia.org/r/#/c/136619/.

All patches mentioned in this report were merged or abandoned - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?
Comment 16 Andre Klapper 2014-11-12 15:19:24 UTC
All patches mentioned in this report were merged or abandoned - is there more work left to do here (if yes: please reset the bug report status to NEW or ASSIGNED), or can you close this ticket as RESOLVED FIXED?
Comment 17 Bartosz Dziewoński 2014-11-12 18:33:58 UTC
As far as I can tell, no patch to fix the problem as specified was merged. There's some disagreement as to whether it is a problem, and if yes, whether it is a problem that can be solved (without disabling caching or something drastic like that, which we obviously can't do). Setting UNCONFIRMED.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links