Currently some Wikitext events go into Edit_11319708 and others go into Edit_11448630. With different sampling rates, this is a recipe for bad data. More detail in my comment here: T93242
Description
Description
Related Objects
Related Objects
- Mentioned In
- T94059: Edit Schema module loaded by EL client side is not being updated
- Mentioned Here
- P422 Edit schema version in production
Event Timeline
Comment Actions
@Krinkle has done some digging around on the ResourceLoader side of things. It appears that the cached version of the schema actually getting loaded by RL for the startup module is an old version.
Comment Actions
Bypassing cache serves the new version, so it's definitely deployed correctly and being exposed:
http://bits.wikimedia.org/en.wikipedia.org/load.php?lang=en&debug=true&modules=schema.Edit&only=scripts
... ,"revision":11448630 ...
Fetching the startup module shows:
[ "schema.Edit", 1381493430,
new Date(1381493430* 1000) Fri Oct 11 2013 13:10:30 GMT+0100 (BST)
Looks like that is $wgCacheEpoch. So ResourceLoaderSchemaModule is probably failing to fetch the RemoteSchema to determine the current cache v....
Wait a second, that class isn't computing an actual timestamp. It's doing mathematical addition on cache epoch with a revision ID. Thus creating an incrementing timestamp, but not actually related to the time the change happened.
This works on an individual module but will fail in practice where multiple modules are requested in a batch with the max() timestamp as the leading url parameter. Thus deploying a change to EventLogging, I suspect, would never result in successful deployment of said change unless another module requested with that schema is also changed in the same deployment.
Comment Actions
The instrumentation from the Edit team seems fine here. The problem is with EL itself, so I've opened an appropriate task and I'll start working on it with top priority.