[08:13:48] Is Redis currently "functional" for executing Jobs? It was perfectly functional back in 1.36, but since 1.37 we're experiencing some issues with cache invalidation not working. Jobs seem to execute, but redis is filled with entries about jobs and never get removed from there. showJobs.php returns 0 pending jobs though [08:15:44] https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/jobqueue/JobQueueRedis.php$100 - JobQueueRedis must be configured in "daemonized" mode and asks for the mediawiki/services/jobrunner service. However, this service seems abandoned and currently doesn't seem to be non functional [08:16:54] https://github.com/wikimedia/mediawiki-services-jobrunner/blob/master/src/RedisJobService.php#L205 - that key doesn't exists in my redis instance. I've searched for it in all MediaWiki code and it doesn't appear anywhere. The file JobQueueAggregatorRedis.php mentioned in the comment was removed from MediaWiki several versions ago [08:18:27] I wouldn't be surprised if redis job queue got broken, since WMF has moved from redis to kafka... [09:15:57] Vulpix: try the Miraheze fork [09:15:59] That should work [09:16:26] https://github.com/miraheze/jobrunner-service [09:17:03] Miraheze still uses the redis setup so it's definitely possible [09:23:15] Oh, so you're removing rootjobs regularly... https://github.com/miraheze/jobrunner-service/commit/de7d72b68abc834dc1cff8372546fc31d27911c2 - Well, that's what I'm experiencing on 1.37, the redis db is bein filled with those. But I'm pretty sure that's a fault on MediaWiki code and not on the job runner service [09:26:37] In fact, I'm not using that service. I'm using this https://www.mediawiki.org/wiki/Manual:Job_queue#Continuous_service which is basically running runJobs.php. I looked at the code of mediawiki/services/jobrunner service to see if it was doing something different that requires such service, and that's where I got the impression it's abandoned and broken [09:27:58] I'll investigate what are the purpose of all those "rootjob" objects and see if it makes sense to be blindly added to redis without deleting them once they're completed... [09:53:36] Vulpix: redis jobrunner is awful software [09:54:48] sigh... I'll have to return back to the old days jobqueueDB [15:36:17] apparently array_shift() flattens array if there is just one element left [15:37:06] just hit it in T313419 (WikiSEO) [15:37:06] T313419: DeferredDescriptionUpdate.php --force: array_shift() converts array into a string leading to a TypeError - https://phabricator.wikimedia.org/T313419 [15:37:59] err [15:38:03] I read the code wrong [15:38:10] it is just plainly a logical error here [15:38:22] going to edit the report I guess [15:40:55] Remilia: where did you get WikiSEO from [15:41:03] it's not line 109 [15:41:19] RhinosF1: GitHub master [15:41:30] I see no changes to that part of the code [15:42:02] currently looking at https://github.com/wikimedia/mediawiki-extensions-WikiSEO/blame/6159367717c1df72c13a96edcef64aef100a4c02/includes/WikiSEO.php [15:43:11] err [15:43:16] sorry, clipboard error [15:43:52] https://github.com/wikimedia/mediawiki-extensions-WikiSEO/blame/6159367717c1df72c13a96edcef64aef100a4c02/includes/DeferredDescriptionUpdate.php#L93 [15:44:48] "$propertyDescription = array_shift( $propertyDescription ) ?? [];" looks *really* weird to me [15:45:20] because it says "get the first element, but if failed, get an empty array" [15:46:02] I downloaded a fresh snapshot when I upgraded to 1.38.2 [15:46:26] Remilia: it doesn't match up quite with github but i think I know where it failed [15:47:05] RhinosF1: I used the Installation instructions from https://www.mediawiki.org/wiki/Extension:WikiSEO — was this the wrong way to install it? [15:47:52] Remilia: no, probably just a commit missing [15:49:09] fetched the one from ExtensionDistributor just now and it looks the same, just the code accounting for different MW versions is gone [15:49:15] the error stays (obviously) [15:51:11] Remilia: array_shift should return the shifted value [15:51:17] I think there is a logic error here, I am not sure array_shift() is even supposed to happen [15:51:18] yes [15:52:04] Remilia: yes so I don't get what's unexpected about it returning a string [15:52:06] judging by the code below which checks for both > 1 and === 1, array_shift() should not be called [15:52:42] RhinosF1: that count( $propertyDescription ) cannot operate on strings? [15:53:06] sorry, I am not quite following [15:54:10] the code goes through these steps: 1) get an array 2) turn the variable with the array into a string 3) attempt to count elements in this same variable, twice [15:54:57] looking at the code below array_shift() call, it says in the comment: // There are multiple page props with the name 'description' present [15:55:04] and the comparison is ">1" [15:55:50] so if we have *two* descriptions returned, after array_shift() this test fails as even if we did not convert it to string, it would only have one entry [15:56:30] yeah, I have no idea how it ever worked [15:56:53] array_shift should have always done that and this should have been broken months [15:57:07] it probably never worked [15:57:13] and I am the first person to use --force [15:58:04] quite possible [15:58:17] i'd say upload a patch dropping array_shift [15:58:34] maybe test it locally first Remilia [15:58:44] that is what I am about to do [15:59:58] not as simple, going to try to fix this properly now [16:00:12] ok [16:00:31] because "$descriptionEqual = strcmp( $propertyDescription, $apiDescription ) === 0;" later is another obvious TypeError [16:01:21] works now [16:02:06] I guess time to remember how to use git-review [16:02:18] you can use the web UI [16:02:33] might be faster for 1 file [16:04:42] the Gerrit UI? [16:05:36] ye [16:16:33] RhinosF1: gerrit asks me to add reviewers and I am not sure what to do here, first time using Gerrit like this :\ [16:16:57] do I just add Reedy haha [16:17:04] Remilia: Octfx would be best [16:17:30] oh. right, the suggestions did not show them so I assumed wrong [16:17:32] thank you [16:18:35] legoktm mcb [16:19:14] oops: sorry for the missping legoktm, I'd like you to review T313394, since we need an "importer" on mw.org [16:19:14] T313394: Special:Tags MediaWiki:Tag-xxx have been translated in FR but I cannot import them - https://phabricator.wikimedia.org/T313394 [16:19:27] Remilia: I have -1'd it [16:19:33] yay [16:19:40] Commit message needs updating to follow guidelines [16:20:09] yes I saw, going to check something existing to make sure I am not an idiot [16:21:38] (disclaimer: I am, but it is irrelevant in this case) and fixed [16:33:26] also, I have a rather weird question regarding magic words: a few weeks ago I have changed the upload path, but old pages using {{filepath still have old URLs showing up; if I try to use {{filepath in a new edit, the output is correct. I purged the cache for a page with this issue and restarted php-fpm to wipe the object cache but it does not seem to help [16:33:52] Vulpix: so...what userrights do I need to give you? :) [16:34:18] but manually tagging edits on 1000+ pages is a bit of a daunting task [16:34:37] legoktm: Not userrights, it's sufficient if you can export a set of translations from twn and import them on mw.org [16:35:10] legoktm: those messages: https://www.mediawiki.org/w/index.php?title=Topic:Wz17brdt8z8yr2qr&topic_showPostId=wzhfxsddjn2b5hya#flow-post-wzhfxsddjn2b5hya [16:36:07] ok, I'll look into this tonight [16:36:21] thanks! [17:51:52] I am absolutely stumped, I have a template that does this: `{{#seo:| image = {{filepath:{{#titleparts:{{PAGENAME}}|1}}Banner.png}}` and due to some magic, seemingly after refreshLinks job runs the "image" page property is filled with $wgUploadPath that has not been used in weeks if not months [17:52:18] but this only happens to template-driven pages when I touch the template [17:53:09] when I try using this magic word on my user page, it generates correct paths [17:53:55] I checked the database dump and there are no instances of the old path outside the comments and text tables + stuff that got freshly filed into page_props