Page MenuHomePhabricator

ResourceLoader: Startup module Last-Modified should take changes to mw.config / LocalSettings into account
Closed, ResolvedPublic

Description

The Last-Modified time of the startup module is the max of the mtimes of all modules, but this doesn't change config changes into account. It should, though. I guess somehow being able to specify a list of config files to check would be best.


Version: 1.17.x
Severity: major

Details

Reference
bz28899

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:26 PM
bzimport set Reference to bz28899.

That's traditionally considered to be $wgCacheEpoch's job, but of course because it's applied so widely that might be overmuch.

Maybe make a hash of configuration variables values that affect the startup module?

(In reply to comment #1)

That's traditionally considered to be $wgCacheEpoch's job, but of course
because it's applied so widely that might be overmuch.

Maybe make a hash of configuration variables values that affect the startup
module?

Hmm, that could be a good idea.

(In reply to comment #2)

(In reply to comment #1)

That's traditionally considered to be $wgCacheEpoch's job, but of course
because it's applied so widely that might be overmuch.

Maybe make a hash of configuration variables values that affect the startup
module?

Hmm, that could be a good idea.

Basically what we're doing in the ResourceLoaderLanguageDataModule (which itself is based on the logic of GlobalDependency)

@Roan: All global variables or the ones exposed in mw.config?

It depends on whether we want to invalidate for the mw.config data, or for what could affect things indirectly (e.g. a global configuration variable can affect composition of other modules, or even presence of modules).

Though depending on how the startup module calculates "everything" it might take that into account already in the 5 minute loop.

To answer myself:

(In reply to comment #4)

@Roan: All global variables or the ones exposed in mw.config?

Just the ones exposed.

Though depending on how the startup module calculates "everything" it might
take that into account already in the 5 minute loop.

It does.

Let's do this using the new getHashModified approach that landed recently. We'd take a hash of the mw.config object in PHP and possibly any other variables we want to take into account. Similar to how LanguageDataModule cache is invalidated based on values of (unversioned) global variables.

Change 119706 had a related patch set uploaded by Krinkle:
ResourceLoaderStartUpModule: Use hashMtime to detect config changes

https://gerrit.wikimedia.org/r/119706

Change 119706 merged by jenkins-bot:
ResourceLoaderStartUpModule: Use hashMtime to detect config changes

https://gerrit.wikimedia.org/r/119706