(Photography by Niek Hidding.)
@Krenair I was referring to this bit:
There exists a helper for this purpose now in core (DeprecationHelper triat). It uses __get and I assume that the concern with that for "old PHP versions" no longer applies, given we now require PHP 5.6+/HHVM.
@Ciencia_Al_Poder From a quick glance, the referenced patch adds a condition for params['wiki'], however I do not see this being set in your configuration. If the configuration has changed or wasn't as described, please provide an updated overview of your DB and ES-related settings.
See also T217846 which is making this harder to test.
There seem to be several major points in time where something significant happened on webperf2001 in the last 7 days.
There should be only one instance of each on a given webperfx001 instance:
Sat, Apr 20
This task was referenced as actionable for aa recent incident.
For the record, the issue with the job queue only affected test wikis and mediawiki.org. As a precaution we paused the job queue for all wikis (including Wikidata and Wikipedia).
@Milimetric Yep. I believe there's also a number of such tasks in Phabricator already (from people finding the warnings), which we can attach as sub tasks as well. Thanks!
- The task description describes a fatal error with the general logic of running jobs. It was caused by fc5d51f1293 9 days ago, and was fixed the same day with 0091dde3b.
- A later comment refers to a separate issue specific to Beta Cluster, where jobs were silently disabled for a while. Details at T215339, since then resolved.
- Comment T220662#5126444 refers to another issue relating to title corruption. This was also reported at T221368 and fixed yesterday.
Fri, Apr 19
BlockDisablesLogin is used on private and fishbowl wikis (otrswiki, officewiki, …). They grant no rights to anons (except for fishbowls chapter wikis and foundationwiki, which do allow reading). In particular, they disallow signup. Blocks are meant to approximate account removal there. For example, after the term for a role like CheckUser or Steward expires, or after a chapter member leaves.
@Daimona Thanks, I didn't realise that regular Page deletion already does this. That makes a good case for handling this here as well, and also means we may have an existing pattern that we can apply with relative easy (being optimistic).
(Tagging steward per mw:Maintainers for initial triage.)
So there are two issues here:
The above patch made the error message different. It can now be found by searching for DatabaseMysqlBase::doSelectDomain or for ("USE centralauth" OR "USE metawiki").
I recall seeing at some point changeset(s) for Scap that did some work toward this end, but can't find them now.
Thu, Apr 18
Assigning to self, to do perf comparison for page view reads with a local install. Comparing the stock default of a db table on sqlite, vs cdb vs static-array. This is an interesting comparison because unlike for MySQL, sqlite would technically be a local disk read just as a file-based l10n cache would be. I would imagine the static array read to be far more efficient (which is the one we proposed). I can still compare cdb file open-read perf between sqlite3 file open-read performance, though.
Another question for @aaron as well - If we start storing this chronologyprotector field in kafka etc. that means it can survive longer and no longer has an expiry like we do for cookies. I vaguely recall an issue in the past where clients that kept the value too long caused subsequent requests to stall for many seconds as MW mistook the unknown value for a value that hasn't appeared yet.
Confirmed to work again on mediawiki.org by making an edit on a template, and confirming from Incognito (cached enabled) that pages using it got the update propagated. Also confirmed via logged-in, and via Translate extension.
@mobrovac Okay, I've looked it over a few more times and am now confident that with this second EventBus patch, we can proceed without the core patch.
At glance, it seems to be like the simplest option would be to standardise on @inheritdoc (option 1) – at least in the short-term.
@Pchelolo Yeah, I also see a few other pre-existing problems here that we're lucky haven't caused problems before.
Assigning to self to start investigating. May need to transfer to Aaron once his day starts :)
That's right. For Wikimedia wikis I found. I usage and do not think it worth announcing via Tech News.
Wed, Apr 17
@Tgr In your example "closing an RFC" is not the same as "closing a task tagged TechCom-RFC". If the task represents only an RFC, then closing it would mean closing the task, there is no reason not to. If the task in question tracks other work, or tracks a general intent for a product or feature, then closing it would mean removing the tag probably. In both cases, it can always be re-tagged or re-opened.
@Dzahn Assuming that with Let's Encrypt, HTTPS will work in modern browsers for all redirects - do we need any of the redirect domains in SAN? Perhaps we don't need any. Afaik all redirect-like domains used in official branding or advertising are actually considered "canonical" for the purposes of this ticket, and would not go to the redirect service (e.g. w.wiki and jobs.wikimedia.org). Is that right?
@Jseddon Will this mean fixcopyright.wikimedia.org gets sunset and redirects to something within this new wiki?
Another note based on a comment from @Milimetric in today's TC meeting.
@daniel No, there are no substitutions on the edit summary apart from link syntax. All other text is preserved as is. I imagine it's not unlikely to have edit summaries like "Fix bug with ~~~" or "Forgot to add ~~~~". example.