[16:34:45] <Remilia>	 hmm T230618 does not yet fix RecentChangesUpdateJob::updateActiveUsers
[16:34:46] <stashbot>	 T230618: ActiveUsersPager's new query logic breaks PostgreSQL compatibility - https://phabricator.wikimedia.org/T230618
[16:34:51] <Remilia>	 only noticed just now
[16:35:59] <Remilia>	 wonder if the change in https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/530620/1/includes/jobqueue/jobs/RecentChangesUpdateJob.php is still missing another column
[16:37:44] <Remilia>	 anomie: would it be correct to reopen this task?
[16:42:01] <Reedy>	 What's the error?
[16:42:13] <Reedy>	 complaining about group by, but a different column?
[17:24:17] <Remilia>	 Reedy: the former
[17:24:28] <Reedy>	 The former what?
[17:24:40] <Remilia>	 exact same issue as before; it was fixed for the page itself but not the job
[17:25:02] <Remilia>	 ERROR:  column "actor_rc_user.actor_name" must appear in the GR
[17:25:02] <Remilia>	 OUP BY clause or be used in an aggregate function at character 76
[17:25:59] <Remilia>	 I am guessing $actorQuery['fields']['rc_user_text'] does not add actor_name into the argument list
[17:27:00] <Remilia>	 the error is a carbon copy of the one I reported for the updateActiveUsers job
[17:27:17] <Reedy>	 > $actorQuery = ActorMigration::newMigration()->getJoin( 'rc_user' );
[17:27:17] <Reedy>	 > var_dump( $actorQuery['fields']['rc_user_text'] );
[17:27:18] <Reedy>	 /var/www/wiki/mediawiki/core/maintenance/eval.php(78) : eval()'d code:1:
[17:27:18] <Reedy>	 string(24) "actor_rc_user.actor_name"
[17:27:39] <Remilia>	 weird :\
[17:29:29] <Remilia>	 time to enable DBQuery logging again
[17:30:15] <Remilia>	 I kind of want a way to trigger this updateActiveUsers job manually so I could get proper detailed logs when I need to, not wait a day or more
[17:31:15] <Reedy>	 try the updateSpecialPages maintenance script?
[17:31:28] <Remilia>	 thanks, will do
[17:34:29] <Remilia>	 Reedy: the postgresql log still has "GROUP BY rc_user_text", and this puzzles me greatly, because the PHP file is definitely updated, and I have upgraded PHP since
[17:36:49] <Reedy>	 At teh start of the query, does it still have the sql comment which tells you what function is calling it?
[17:37:06] <Remilia>	 Sep 15 19:53:26 db postgres[71105]: [16-2] azurlane_wiki STATEMENT:  SELECT /* RecentChangesUpdateJob::updateActiveUsers
[17:37:07] <Remilia>	 yes
[17:37:50] <Remilia>	 this makes absolutely no sense
[17:38:23] <Remilia>	 like, here's a screenshot: https://i.koumakan.jp/2019-09-15/1568569081.png
[17:39:33] <Reedy>	 pastebin the full SQL query?
[17:40:57] <Remilia>	 https://paste.ee/p/FVz38
[17:41:28] <Reedy>	 it's seemingly doing the rest of the join...
[17:41:57] <Reedy>	 You can do the same thing I pasted above in eval.php
[17:42:11] <Remilia>	 I just cannot fathom why would there still be rc_user_text when the code does not have it
[17:42:38] <Remilia>	 restarting PHP should clear any code cache
[17:42:47] <Remilia>	 not to mention upgrading 
[17:44:36] <Reedy>	 Have you got $wgMultiContentRevisionSchemaMigrationStage set to something else in LocalSettings.php?
[17:46:22] <Remilia>	 no
[17:54:26] <Remilia>	 yeah this makes no sense, I put "nonexistentcolumn" straight in the GROUP BY line
[17:54:36] <Remilia>	 and it still does rc_user_text
[17:55:07] <Remilia>	 and the worst part is I cannot even log this because jobs logging in monolog still refuses to work
[17:56:36] <Reedy>	 If you put a syntax error in the file, does it still execute fine?
[17:56:48] <Vulpix>	 just to be sure, are you editing the correct file in the correct *folder* and *server*?
[17:56:57] <Remilia>	 Vulpix: it is the only server
[17:57:17] <Remilia>	 and yes it is the correct directory, since the other fix was done in the same structure and worked fine
[18:22:13] <Remilia>	 Reedy: I am not sure whether it was editing the file several times to introduce syntax errors, or something else, but it might have been fixed (no new errors so far) yet I have no idea why and where would it cache code across multiple PHP upgrades
[18:24:32] <Remilia>	 updateSpecialPages does not queue any jobs though
[18:45:42] <Remilia>	 I'll report back if the errors appear again
[18:48:24] <Remilia>	 since this confuses me greatly as it's been a whole month since I made the edit
[18:49:48] <Reedy>	 I do wonder if those want backporting
[18:50:52] <Reedy>	 "are broken on 1.33"
[18:50:54] * Reedy goes with yes
[18:51:55] <Reedy>	 Remilia: Are you using it on 1.33?
[18:52:16] <Remilia>	 also, unrelated: I finally made a developer account and submitted a patch for SquidPurgeClient :\
[18:52:26] <Remilia>	 Reedy: yes, I applied the patches
[18:52:32] <Remilia>	 to my 1.33 back on Aug 16
[18:52:44] <Reedy>	 I've just officially backported them
[18:53:21] <Remilia>	 \o/
[18:53:54] <Reedy>	 I'm glad someone menitoned it..
[18:54:07] <Reedy>	 As if it didn't go into 1.33.1 that would've been a shame, as the patchs do exist
[18:57:38] <Remilia>	 Reedy: may I trouble you with a different question? it is my first attempt at submitting a patch to MW, so I was wondering if I made any mistakes there; it is in T29658
[18:57:39] <stashbot>	 T29658: SquidPurgeClient fails on FreeBSD; incorrect constants + MSG_EOR w/ SOCK_STREAM - https://phabricator.wikimedia.org/T29658
[18:59:04] <Remilia>	 I am mostly concerned whether it was all right to also include the additional headers in the patch
[18:59:23] <Remilia>	 or if I should have created a second commit for that
[19:02:13] <Remilia>	 Reedy: see commit message, EOR is mentioned there
[19:02:48] <Reedy>	 https://www.php.net/manual/en/function.socket-send.php doesn't document that
[19:02:50] <Remilia>	 the pool connection is SOCK_STREAM
[19:03:05] <Reedy>	 I'd probably split the headers to a seperate patch
[19:03:12] <Reedy>	 That should be much easier to review and merge
[19:03:28] <Remilia>	 http://man7.org/linux/man-pages/man2/send.2.html
[19:03:52] <Remilia>	        MSG_EOR (since Linux 2.2) Terminates a record (when this notion is supported, as for sockets of type SOCK_SEQPACKET).
[19:05:40] <Remilia>	 Reedy: having EOR set on BSD systems results in an error
[19:06:03] <Remilia>	 unless it is a SOCK_SEQPACKET socket
[19:09:09] <Remilia>	 http://fxr.watson.org/fxr/source/kern/uipc_socket.c?v=OPENBSD;im=bigexcerpts#L378
[19:27:51] <Reedy>	 Remilia: Can you split the header changes to a new patch?
[19:28:22] <Remilia>	 Reedy: going to check the manuals to see how to go about it
[19:28:35] <Reedy>	 You can make a patch entirely through the gerrit interface if you want
[19:28:53] <Reedy>	 Depending on how you setup the patch to push to gerrit, it should be easy
[19:29:15] <Remilia>	 I used the manual on the wikitech site, submitted used git review -R
[19:29:19] <Remilia>	 using even
[19:29:40] <Reedy>	 did you use a branch?
[19:35:25] <Remilia>	 I just uploaded the updated patch set 
[19:35:32] <Remilia>	 used git-review -d ...
[19:35:45] <Reedy>	 so that's probably a no then
[19:36:06] <Remilia>	 I did use a branch when I made the first one
[19:36:32] <Remilia>	 but I was interested in the -d part
[19:36:39] <Remilia>	 it probably does not matter on Gerrit side?
[19:37:58] <Reedy>	 -d sets up a branch when it's bringing it for download