These can cause writes on GET/HEAD and would break the site in read-only mode where it not for the hacky wfReadOnly() check in saveSettings. They can still break the site on master failure.
|mediawiki/extensions/Translate : master||Defer the ApiTranslateUser::trackGroup saveSettings() call|
|mediawiki/extensions/ContentTranslation : master||Defer the user update in enableCXBetaFeature()|
|Open||aaron||T88445 MediaWiki active/active datacenter investigation and work (tracking)|
|Resolved||aaron||T94480 Audit and fix extensions that call saveSettings() to lazy-set preferences when loaded|
- Mentioned In
- T92357: Fix problematic database master queries performed on HTTP GET/HEAD
rETRA5b0adf4af68d: Defer the ApiTranslateUser::trackGroup saveSettings() call
rMEXT3e5817589b6c: Updated mediawiki/extensions Project: mediawiki/extensions/Translate…
rECTX39bc6b63d242: Defer the user update in enableCXBetaFeature()
rMEXTc8b5a1de1e3b: Updated mediawiki/extensions Project: mediawiki/extensions/ContentTranslation…
I see a few anti-patterns:
a) Adding preferences for beta features or the like because a new feature was made and the default was not applied to that user. I don't see why those can't just use application defaults (accounting for the generic opt-in preferences) and log the changes somewhere for analytics. If they really have to update the DB it could be via jobs I suppose (rather than whenever preferences just happen to be loaded).
b) Using hidden "preferences" to track "last visited" data (e.g. NewPagesFeed). These could probably just use AJAX, since that page is JS only anyway. I think Echo and other extensions may do this kind of thing to...maybe the same applies there.
Also, one related thing to do is to add wfReadOnly() checks there since some callers seem OK with doing nothing were as other don't, and I can't change User until the callers are updated.