My conscious is a jukebox
Tue, Oct 15
I'm running into the same issue we had with SVG Translate where responses are getting truncated; see T217815.
@bd808 From my research this has something to do with Nginx (which I think we use?) and/or fastcgi. Solutions point to a permissions issue, just as the error message suggests:
I'm having the same problem with the wikiwho tool. Responses get truncated at 64 KB. If I make requests that give smaller responses, everything works fine.
Per our discussion, we are going to stay with the status-quo which is to show the timestamp according to the browser settings. The format of the timezone specified by the user's preferences is not trivial to parse. More at T235294: Add method to mw.user to get the preferred timezone offset.
Fri, Oct 11
Thu, Oct 10
I had this issue when I tried https://eu.wikipedia.org/wiki/Thorichthys_ellioti?uselang=fr (on master) in Chromium. @ifried is reporting similar issues with the deployed Firefox extension.
Wed, Oct 9
I am guessing the user agent is not actually being read by the software (at least when it determines what tags to apply). It's just recording the method used to edit. For example I can edit on desktop using the mobile UI, and vice versa. In this sense it is no different than the tag added when using HotCat or Huggle (both of which suggest you're using desktop), or even AutoWikiBrowser which narrows it down to just Windows. Also there are user scripts that add "(using Foobar script)" to the edit summary, which indicate desktop. Then consider the Pageviews-API; If there is one pageview and one edit to [[Foo bar]] and it is mobile web, I know the single editor is using mobile web.
Tue, Oct 8
Thanks. I'm looking forward to it!
Mon, Oct 7
Thanks for the report. This error was due to maintenance the Cloud Services team was doing earlier today. It should be working now.
Pretty amazing of them to do this sort of code review for us!
Fri, Oct 4
I've been thinking of requesting +2 for PageTriage - thoughts?
it was under the Kanban board because it was created as a sub task. Should I ensure that I remove that tag each time?
Good stuff! Probably could use QA.
Much appreciated, @DannyS712! I think this is relevant to our work, so tagging with Community-Tech seems appropriate, but in general please let us manage what columns tasks go under, and whether they belong on the Kanban board. Thanks!
Thu, Oct 3
The automatic merges such as with Special:MergeItems certainly seems applicable. Manual merges probably shouldn't apply because they are not (semi-)automated, and I don't think we can reliably detect them anyway.
Wed, Oct 2
Relevant issue on Wikiwho's GitHub: https://github.com/wikiwho/WhoColor/issues/7
Thanks DannyS712! Everything looks good in my testing but we'll put this through QA just in case.
Tue, Oct 1
T187379: Hook up Grant metrics with TWN is an example of when we did this in the past.
I'm going to go ahead and move to Needs Review. I think T225774#5319960 and T225774#5320840 summarize the issue. Basically there doesn't appear to be a workable solution. This query was always really slow, and apparently we're at the point where there are so many revisions that it just won't finish. I suggest we retire the "Pages with most revisions" database report.
This should be addressed, but I don't think T234067: Page triage leads to a one way action in some cases specifically is a huge concern. The idea is to unreview a page so that you can take actions on it like add tags using the toolbar. I don't know why you would do this to a page you created. There is a confirmation modal about adding pages to the queue, so that hopefully will prevent mistakes. I'm going to move this to our parent board as we typically will discuss/triage/estimate before putting a task on the Kanban board.
There have been more reports of this. Going off of the error logs for XTools, the last burst of 503s from the MediaWiki API happened from around 11:00 to 12:00 UTC on October 1.
Fri, Sep 27
This is a fun idea! I take it this for XTools ? Is all of the data already available to us (on the db replicas)? If so we might remove MediaWiki-extensions-Translate and MediaWiki-extensions-TranslationNotifications to reduce noise.
PR merged, not sure if we are still investigating the issue with Miniatlas.
Thu, Sep 26
If possible, we should also format the date to match the user's on-wiki preferences.
Wed, Sep 25
Eek, sorry! We recently did some server maintenance (T232786) and missed a very important step. It should be functioning again. Apologies for the disruption!
Tue, Sep 24
@Andrew All set! Everything is now running on Buster, and I've deleted the old VMs. We do not need the additional quota anymore. Thanks for the help!
Mon, Sep 23
Sat, Sep 21
SQL Optimizer works by putting a SLEEP(1) in the query and EXPLAINing the query using the process ID. It is only but so smart, unfortunately. Here it went with:
SELECT SLEEP(1), DISTINCT page_id FROM page
Fri, Sep 20
Twinkle issue: https://github.com/azatoth/twinkle/issues/709
This seems like another example where WhoColor is incorrectly putting things together. The normal WikiWho API attributes the Olympia link to https://tr.wikipedia.org/w/index.php?diff=4019869 which appears to be correct.
That did it! Thank you :)
Thu, Sep 19
There is a thread on checkuser-l about this. At least three users intermittently got 503s today / this week when using Special:CheckUser. I don't know if it's related, but I'm assuming what @DannyS712 experienced is also intermittent, which suggests some broader issue. There were no recent changes to the CheckUser extension https://github.com/wikimedia/mediawiki-extensions-CheckUser/commits/master