User Details
- User Since
- Dec 12 2020, 11:36 AM (295 w, 2 d)
- Availability
- Available
- IRC Nick
- zabe
- LDAP User
- Zabe
- MediaWiki User
- Zabe [ Global Accounts ]
Wed, Aug 5
Sun, Aug 2
This also affects https://gerrit.wikimedia.org/g/mediawiki/extensions/GlobalUsage/+/3ab68a74514cd9222a5c4e87e85cd8c6aee5b71a/includes/GlobalUsageQuery.php#197 since we want to access the categorylinks table of commons from other wikis.
Fri, Jul 31
Wed, Jul 29
Should be fixed as part of T431518.
Should be fixed as part of T431518.
Should be done
I can do it
Mon, Jul 27
@Scott_French could you check if the next run goes smoothly?
Sun, Jul 26
Fri, Jul 24
Thu, Jul 23
Yes we want to check the deletion status in the query. After looking a bit, I do not see a real way to fix this query without adding an index on (file_name, file_deleted).
Wed, Jul 22
So if I compare the query to the one before T416548: Start reading from file table on wmf production, it clearly seems the file schema migration is related to the query getting significantly worse.
Tue, Jul 21
Mon, Jul 13
@sbassett could you make this public?
Jul 8 2026
Jun 30 2026
Looks like a dupe of T371617.
Jun 25 2026
I think this probably caused the global edit count of all users who had edits in apiportalwiki to be off now. We might want to run RecalculateGlobalEditCount.php.
Jun 24 2026
Jun 23 2026
I would assume this to be caused by T428970.
Is it the plan to actually delete the wiki? If so, we could delete the relevant data from the centralauth tables, i.e. the localuser table. That should fix these kind of issues.
Jun 20 2026
@JAllemandou The wait_for_namespace_data task failed for the querypage_most_categories_monthly DAG. Is it a random failure, or is there a bug in the config?
Jun 17 2026
I can confirm it is related to the file migration schema. I set mw-experimental to read old and the correct thumbnails appear.
Will check
Jun 14 2026
Could be caused by T428930: Set up deployment-db15 with Trixie and wmf-mariadb1011.
Jun 11 2026
Jun 7 2026
This is how the query in the read old looks like.
Jun 5 2026
Would it be fine to also allow users in the nda group to access zarcillo?
Jun 4 2026
ikiadmin2023@10.64.16.77(commonswiki)> explain SELECT * FROM (SELECT file_id AS `img_file_id`,fr_id AS `img_filerevision_id`,file_name AS `img_name`,fr_size AS `img_size`,fr_width AS `img_width`,fr_height AS `img_height`,fr_metadata AS `img_metadata`,fr_bits AS `img_bits`,ft_media_type AS `img_media_type`,ft_major_mime AS `img_major_mime`,ft_minor_mime AS `img_minor_mime`,fr_timestamp AS `img_timestamp`,fr_sha1 AS `img_sha1`,fr_actor AS `img_actor`,image_actor.actor_user AS `img_user`,image_actor.actor_name AS `img_user_text`,comment_img_description.comment_text AS `img_description_text`,comment_img_description.comment_data AS `img_description_data`,comment_img_description.comment_id AS `img_description_cid` FROM `file` JOIN `filerevision` ON ((file_latest = fr_id)) JOIN `filetypes` ON ((file_type = ft_id)) JOIN `actor` `image_actor` ON ((actor_id=fr_actor)) JOIN `comment` `comment_img_description` ON ((comment_img_description.comment_id = fr_description_id)) WHERE file_deleted = 0 ) `sqb1` WHERE (img_timestamp < '20260317181512' OR (img_timestamp = '20260317181512' AND (img_name <= 'IN_Winamac_160372_1962_24000_geo_(TIF).tif'))) ORDER BY img_timestamp DESC,img_name DESC LIMIT 501 ; +------+-------------+-------------------------+--------+-----------------------------------------+---------+---------+--------------------------------------------+-----------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+-------------------------+--------+-----------------------------------------+---------+---------+--------------------------------------------+-----------+----------------------------------------------+ | 1 | SIMPLE | file | ALL | file_name,file_latest | NULL | NULL | NULL | 121806109 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | filerevision | eq_ref | PRIMARY,fr_actor_timestamp,fr_timestamp | PRIMARY | 8 | commonswiki.file.file_latest | 1 | Using where | | 1 | SIMPLE | filetypes | eq_ref | PRIMARY | PRIMARY | 2 | commonswiki.file.file_type | 1 | | | 1 | SIMPLE | image_actor | eq_ref | PRIMARY | PRIMARY | 8 | commonswiki.filerevision.fr_actor | 1 | | | 1 | SIMPLE | comment_img_description | eq_ref | PRIMARY | PRIMARY | 8 | commonswiki.filerevision.fr_description_id | 1 | | +------+-------------+-------------------------+--------+-----------------------------------------+---------+---------+--------------------------------------------+-----------+----------------------------------------------+ 5 rows in set (0.003 sec)
Jun 1 2026
May 31 2026
May 11 2026
May 10 2026
@sbassett this can be made public.
May 8 2026
May 7 2026
May 6 2026
@xcollazo the DAG failed. Could you tell me what the underlying error is?
As @Marostegui said there was an incorrect schema for pplwiki. I would assume that was given by the fact that the wiki was created during the migration phase.
May 5 2026
It now looks good to me. @TheDJ could you double check?
Should be fixed.
May 4 2026
We’ll definitely check to see if they’re still needed. And yes, if it turns out they’re not needed, we’ll drop them.
May 3 2026
May 2 2026
So drifts are reappearing, currently enwiki is back to 18 drifts.
It is literally force for some reason: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/UrlShortener/+/refs/heads/master/includes/UrlShortenerUtils.php#145
May 1 2026
Please no
I fixed the drifts on all wikis except commons. If no new drifts occur (which I really hope), I will fix them on commons as well.