Mentioned in SAL (#wikimedia-operations) [2024-06-07T19:42:13Z] <dduvall@deploy1002> Finished scap: Backport for [[gerrit:1040081|mediawiki.diff: Fix color regression and also use one more token (T366845)]] (duration: 16m 10s)

Mentioned in SAL (#wikimedia-operations) [2024-06-07T19:28:35Z] <dduvall@deploy1002> dduvall: Backport for [[gerrit:1040081|mediawiki.diff: Fix color regression and also use one more token (T366845)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-06-07T19:26:03Z] <dduvall@deploy1002> Started scap: Backport for [[gerrit:1040081|mediawiki.diff: Fix color regression and also use one more token (T366845)]]

Change #1040081 merged by jenkins-bot:

[mediawiki/core@wmf/1.43.0-wmf.8] mediawiki.diff: Fix color regression and also use one more token

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

Change #1040081 had a related patch set uploaded (by Dduvall; author: VolkerE):

[mediawiki/core@wmf/1.43.0-wmf.8] mediawiki.diff: Fix color regression and also use one more token

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

Change #1040212 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.diff: Fix color regression and also use one more token

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

Thanks @Mormegil, @Jdlrobson and @Pols12 for the digging, patch provided.

Change #1040212 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.diff: Fix color regression and also use one more token

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

(Just for reference: ⚫ is in code because of T176485.
Per Jdlrobson’s investigations, this issue is a regression from MW-1.43-notes (1.43.0-wmf.8; 2024-06-04).)

I noticed afterwards that disabled setting is from Reference Tooltips gadget. Remains my original problem.

My situation is not what you are saying. I said it twice that I didn't set a global value for this preference. What you say in the task description is not true. This is not the problem I'm reporting.
Once again. I don't have global setting. If I view it not logged in, Reference Previews is on. If I view it logged in, Reference Previews is off, despite I never set it off, in a language version I haven't visited recently. You can replicate it as I described before. In some languages I can change the setting, in some languages I can't, the setting is disabled. "Set a local exception" is not present, because I don't have global value set, I assume. Please replicate and verify.

I can't even change the value, because there is no Set a local exception for this global preference. On some language versions it is possible to change it.

If there is no local exception, the preference is global.

The task is to fix the bug.

Reference Previews default value for logged in users does not match the default value for not logged in users.
Steps to replicate the issue (include links if applicable):

Change #1015525 merged by jenkins-bot:

[mediawiki/extensions/Cite@master] Preserve reflist CSS in dynamic mode

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

在ざいT366419#9857143中ちゅう，@Bean49写うつし道どう：

The function works consistent with the setting. The problem is that a couple of days ago the setting changed from on to off. Even now if I go to a new language version, dewiki, frwiki or eswiki, the setting is off by default. I didn't set global value for this preference. I don't use the Reference Tooltips gadget, it is not set on by default. It happened to others too on huwiki.

The train has reached Wikidata.org - badges appear to work again for me. Can someone confirm?

The others are much lower volume, and at a glance, there were many different stack traces coming from many different components, including some semi-abandoned ones like LiquidThreads and FlaggedRevs, so presumably they have been there for not just 2 years but 10+ years. You can look through the stack traces, file tasks and write patches for each one, but it doesn't seem worth the effort to me.

Is that fix "just" for 70% of the requests? Do the others need addressing too?

Change #1039262 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Read block data from replica in event logging code

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

Change #1039262 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/WikimediaEvents@master] Read block data from replica in event logging code

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

That code was introduced in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/832148 almost 2 years ago, so this doesn't seem terribly urgent. It looks like an easy fix though.

Almost 70% of the log entries in @Ladsgroup's search have this stack trace:

Let me make my stance clearer:
There are three types of template styles here:

• Templates that are used above 30% of pages in Commons: They are adding hundreds of millions of rows to templatelinks and as such we have no choice but to move them into common.css/etc. This is an official recommendation from DBA point of view to improve stability of wikis.
• Templates that are used above 50% of pages in other wikis: My personal suggestion as a random person in the internet is to move them to common.css since template styles bloat HTML of the page, adds to parsercache, requires a lot of minification (on every parse vs. a couple times a day given how aggressively we cache RL modules in every layer), adds network, adds data transfer to users, it is less efficient because of client-side caching, etc. etc.
  • Sure it has downsides, it needs to be taken into account when deciding what to move and/or those downsides should gets mitigated via ideas volunteers put above.
  • But at the end of the day, this is my personal opinion, nothing more and I think e.g. our performance God in residence @Krinkle should weigh in here. He might know something I don't :)
• Anything else: Should use template styles.

Re-opening since the issue is reproducible in frwiki wmf.7 - added some clarification in the issue description.