In T184633#4955354, @FDo64 wrote:

@Niharika, @Framawiki,@Louperivois: Hi ! I’m back today with a new idea, probably easiest to implement.
I’m currently working on Special:UnusedCategories and there is a magic word doing the same kind of job I’m requesting:

__EXPECTUNUSEDCATEGORY__

Could we envisage creating the following magic word?

__EXPECTUNUSEDTEMPLATE__

Then, all templates containing this magic word should be filtered in the Special:Unusedtemplates page.
Your thoughts?
Regards

In T234684#5560354, @Nuria wrote:

@elukey I think increasing timeout would do little here the 4 year query for browsers is not executable (cold cache) in druid so superset will not be able to do it either. Now, the puzzling part is that once cache is warm (and i warmed it up by hand) superset should be able to load that data. This is probably an issue bigger than this ticket.

I have never encountered this problem. The updates in the main page usually happen in few seconds.

Thanks for the answer. I assume that "it found" should be read as "IAB found".
What I don't understand is how "somewhere on some wiki" should be read or interpreted.
Why should "somewhere on some wiki" have an influence on a specific reference, including a specific access date, in a specific article in a specific wiki?
We do not want IAB to replace a reference to a site with a random snapshot that is "a guaranteed working snapshot with *similar* data". We want a snapshot that is likely to contain the *same data* as was present at "the specified access date". In this particular case I am told that there is a significant difference between the contents from December 2018 and from June 2019.

Mentioned in SAL (#wikimedia-operations) [2019-10-10T05:51:55Z] <marostegui@cumin1001> dbctl commit (dc=all): 'Depool db1112 for PDU maintenance T227536', diff saved to https://phabricator.wikimedia.org/P9294 and previous config saved to /var/cache/conftool/dbconfig/20191010-055153-marostegui.json

Mentioned in SAL (#wikimedia-operations) [2019-10-10T05:47:40Z] <marostegui> Depool db1084 db1083 db1076 db1118 for PDU maintenance - T227536

I made some more null edits - maybe the job queue is behind?

A prefilled reason can be specified using &wpReason=foo at the end of the link to delete the redirect.

I just created Translations:API:Revisions/4/zh. But it didn't shown in API:Revisions/zh.

In T235141#5562061, @DannyS712 wrote:

What languages aren't showing up?

zh

@Eileenmcnaughton i'm just bumping this as the import still isn't importing the file{F30613254}. Can you take a look please and advise on the next steps?

In T235141#5562060, @A2093064 wrote:

@DannyS712 And
https://www.mediawiki.org/wiki/Manual:CleanupEmptyCategories.php
https://www.mediawiki.org/wiki/Help:Extension:GWToolset (New translation is not merged into current page)
https://www.mediawiki.org/wiki/Extension:SimpleMathJax

@DannyS712 And
https://www.mediawiki.org/wiki/Manual:CleanupEmptyCategories.php
https://www.mediawiki.org/wiki/Help:Extension:GWToolset (New translation is not merged into current page)
https://www.mediawiki.org/wiki/Extension:SimpleMathJax

Page creation log entries should be shown by default

Looks to have been resolved

Awaiting product input from @Niharika, per T160233#5483998

This is blocking https://gerrit.wikimedia.org/r/525147.

Made a few null edits, and it works now

Host ready for on-site + switch disablement steps

Change 542002 merged by Marostegui:
[operations/puppet@production] site.pp: Remove db2057 puppet references

Change 542003 merged by Marostegui:
[operations/dns@master] wmnet: Remove db2057 production DNS entries

cookbooks.sre.hosts.decommission executed by marostegui@cumin1001 for hosts: db2057.codfw.wmnet

• db2057.codfw.wmnet (PASS)
  • Downtimed host on Icinga
  • Downtimed management interface on Icinga
  • Wiped bootloaders
  • Powered off
  • Set Netbox status to Decommissioning
  • Removed from DebMonitor
  • Removed from Puppet master and PuppetDB

Change 542003 had a related patch set uploaded (by Marostegui; owner: Marostegui):
[operations/dns@master] wmnet: Remove db2057 production DNS entries

Change 542002 had a related patch set uploaded (by Marostegui; owner: Marostegui):
[operations/puppet@production] site.pp: Remove db2057 puppet references

Should be live now. Please let me know if that fixed the problem

Change 539333 merged by jenkins-bot:
[mediawiki/core@master] Fix some phan warnings for too many params (part 1)

Mentioned in SAL (#wikimedia-operations) [2019-10-10T04:53:54Z] <marostegui> Deploy schema change on db1061 (s6 eqiad master) - T233135 T234066

Mentioned in SAL (#wikimedia-operations) [2019-10-10T04:53:54Z] <marostegui> Deploy schema change on db1061 (s6 eqiad master) - T233135 T234066

Change 539333 had a related patch set uploaded (by Krinkle; owner: Daimona Eaytoy):
[mediawiki/core@master] Fix some phan warnings for too many params (part 1)

Change 539335 had a related patch set uploaded (by Krinkle; owner: Daimona Eaytoy):
[mediawiki/core@master] Fixup phan warning toomanyparams (part 2)

Mentioned in SAL (#wikimedia-operations) [2019-10-10T04:43:58Z] <marostegui> Depool labsdb1011 for recloning - T235016

Change 542000 merged by Marostegui:
[operations/puppet@production] dbproxy1011: Depool labsdb1011 to reclone it from labsdb1012

https://commons.wikimedia.org/wiki/File:Rainbow_trout_transparent.png

Change 542000 had a related patch set uploaded (by Marostegui; owner: Marostegui):
[operations/puppet@production] dbproxy1011: Depool labsdb1011 to reclone it from labsdb1012

Here are some suggestions on what to smoke test for any changes to the fallback loop. You could check all the following situations, each time looking for errors in the browser console and checking the contents of mw.centralNotice.data.

In T233594#5559135, @dom_walden wrote:

We also modified BlockManager::trackBlockWithCookie which has caused us problems in the past (e.g. T226777 and T227901). Just in case, I attempted to reproduce the bugs in T227901 and T226777, but could not.

@dom_walden Should we close T227901: PHP warning on attempting to set a block cookie after CentralAuth auto login in that case?

Thanks

• re-enable rule
• action set to "only the first time this rule matches"
• Change this task to declined
  • I'm going to leave this as "resolved" because we did something.
• Trout @DannyS712

Change 541564 merged by jenkins-bot:
[performance/fresnel@master] compute: Rename compareStdev() to diffStdev()

Change 540502 merged by jenkins-bot:
[mediawiki/vagrant@master] Drop HHVM support

Change 540502 merged by jenkins-bot:
[mediawiki/vagrant@master] Drop HHVM support