Page MenuHomePhabricator

EventLogging modules do not invalidate, since effective mtime is always $wgCacheEpoch
Closed, ResolvedPublic


Script that can be copied into phpsh to see the problem

EventLogging modules use the revision as the modified time (except on error, in which case 1 is used).

The problem is that ResourceLoaderStartupModule considers $wgCacheEpoch ( The effective mtime is:

max( $moduleMtime, wfTimestamp( TS_UNIX, $wgCacheEpoch ) );

The default $wgCacheEpoch (in DefaultSettings.php) is '20030516000000', which translates to 1053043200, already far greater than the latest revid on Meta. On a real wiki, it will be higher still, since it can be manually set (it is '20130101000000' in production) and on non-production wikis effectively defaults to the mtime of LocalSettings.php.

This means changes to the schema never actually update the effective version. I caught this while using the localStorage module storage (even hard-refreshing, which ideally should not be necessary, does not work around this problem).

I'm planning to fix it by adding the revid to the UNIX time version of the epoch.

Version: unspecified
Severity: normal




Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 3:00 AM
bzimport set Reference to bz60942.

Change 111731 had a related patch set uploaded by Mattflaschen:
Have mtime as calculated by startup module increase on schema change

Change 111731 merged by jenkins-bot:
Have mtime as calculated by startup module increase on schema change

Ori, this shouldn't have affected the stored log data, right? I know it affected clientValidated (since new events wouldn't validate against the out of date schema), but it doesn't look like that affects the server's behavior.

Actually, I think it might have sometimes, since it would also affect which revid is passed in the JSON to event.gif, so I think it could be considered invalid on the server too.

[moving from MediaWiki extensions to Analytics product - see bug 61946]