resourceloader: Limit module_deps write lock to unique index


resourceloader: Limit module_deps write lock to unique index

Follows-up 1d15085bb3.

The column has a unique index for module name and skin/language pair.
Previously the write lock was on module name, which meant that
shortly after deployment, the following happens:

  • Files change on disk.
  • (1-5min pass)
  • First startup module request after 5min http-cache expires. Detects one or more changes and updates the version hash of that module.
  • Web client subsequently requests this module (if used on that page). The first time that request comes in, it's a varnish cache miss and will make RL load all files from disk related to that module and update the cache index in the module_deps table. At this point most popular skin/lang pairs fail, except one. As a result, the other rows remain stale.
  • (7-30 days varnish expiry pass OR another change to the module deploys)
  • Web client requests this module and tries to update its skin/lang pair for that module.

One simple change in January 2016 changes jquery.tablesorter to load
a PNG file instead of a GIF file. Now, over a year later, there are
still a dozen skin/lang pairs in enwiki.module_deps with stale data,
which is causing various suble bugs, as well as filesystem calls for
files that don't exist.

Ref T113916 (refactor module_deps).
Ref T158105 (stale cache bug).

Bug: T158105
Change-Id: Ib6c024bfa8d35ce2d622ba4242291daedb507d5e


KrinkleAuthored on Feb 14 2017, 8:55 PM
rMWe7b57d881aaf: resourceloader: Use upsert() instead of replace() for module_deps write