Last modified: 2014-02-26 12:55:20 UTC
Created attachment 14502 [details] 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 (https://git.wikimedia.org/blob/mediawiki%2Fcore.git/ae03d1a0a38b7aa60a02843ef1e55a680c0166f2/includes%2Fresourceloader%2FResourceLoaderStartUpModule.php#L151). 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.
Change 111731 had a related patch set uploaded by Mattflaschen: Have mtime as calculated by startup module increase on schema change https://gerrit.wikimedia.org/r/111731
Change 111731 merged by jenkins-bot: Have mtime as calculated by startup module increase on schema change https://gerrit.wikimedia.org/r/111731
Thanks, Matt.
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]
