This happened during yesterday's update of the sites table… I hope we can kill the sites table entirely at some point (see T117458 and other tickets).

Also IMO that module should not exist at all, but we should do an API request when we actually need the data (that also requires building an API for sites, of course).

I discussed it with @hoo yesterday (prior to the task being filed).

I suspect it may be related to the various (indirect) APC layers Wikidata/Wikibase has to cache the information used by this module's getScript and getDefinitionSummary methods. As such, once a change was made to the underlying data, it took many rounds before becoming "eventually consistent" on the new value as various servers continued to serve the older value from cache when "re-computing" the module hash.

The startup module is cached for approx. 5 minutes. One of the APC keys I spotted had an expiry of 10 minutes.

This is still happening:

Tuesday, May 10th, 2016
02:13 <perflogbot> mw.config.values.wbSiteDetails: ndCefMab -> FZFlN+VX (changed after 6 days and 56 minutes)
02:18 <perflogbot> mw.config.values.wbSiteDetails: FZFlN+VX -> ndCefMab (changed after 5 minutes and 3 seconds)
02:43 <perflogbot> mw.config.values.wbSiteDetails: ndCefMab -> FZFlN+VX (changed after 25 minutes and 21 seconds)