Instead of displaying just one of the two logs when viewing page-nonspecific log lists, it would make more sense to simply have history merges generate a single log entry that is associated with multiple pages simultaneously. No idea how challenging that would be technically, but it seems the better solution in theory, right?

Closed as a duplicate as (to me) it seems like the same as T395168, but feel free to reopen if it's different :)

Change #1211135 had a related patch set uploaded (by Reedy; author: Reedy):

[mediawiki/core@master] LogPage: Set $type property to '' if null passed in constructor

https://gerrit.wikimedia.org/r/1211135

Change #1206388 merged by jenkins-bot:

[mediawiki/core@master] Pager: Clamp date overflow to avoid invalid offset timestamp

https://gerrit.wikimedia.org/r/1206388

Change #926674 abandoned by SD0001:

[mediawiki/core@master] api: allow querying logevents by logid

Reason:

done in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1187014

https://gerrit.wikimedia.org/r/926674

Oh? I didn’t know this task ever existed but the module now has the leids parameter introduced by T309483.

Change #1206388 had a related patch set uploaded (by Ammarpad; author: Ammarpad):

[mediawiki/core@master] pager: Clamp date overflow to avoid invalid offset timestamp

https://gerrit.wikimedia.org/r/1206388

Still seeing these on 1.46.0-wmf.2.

Even after refreshing the stats, the optimizer seems to be choosing the wrong plan. I've filed a MariaDB bug (https://jira.mariadb.org/browse/MDEV-38072) but I believe we should reconsider adding the ignore hint back to the code if this feature is important and worth the possible pain of maintaining it in code as I've mentioned at T405476#11363865

Wow, the stats are so out of date, no wonder why the optimizer is going nuts - let's see how this works with a refresh on the stats. :

+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
| database_name | table_name | index_name | last_update         | stat_name    | stat_value | sample_size | stat_description                  |
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
| enwiki        | logging    | log_times  | 2022-05-26 17:07:07 | n_diff_pfx01 |   87385704 |          20 | log_timestamp                     |
| enwiki        | logging    | log_times  | 2022-05-26 17:07:07 | n_diff_pfx02 |  112955046 |          20 | log_timestamp,log_id              |
| enwiki        | logging    | log_times  | 2022-05-26 17:07:07 | n_leaf_pages |     167888 |        NULL | Number of leaf pages in the index |
| enwiki        | logging    | log_times  | 2022-05-26 17:07:07 | size         |     192064 |        NULL | Number of pages in the index      |
+---------------+------------+------------+---------------------+--------------+------------+-------------+-----------------------------------+
4 rows in set (0.003 sec)

Yeah, that URL gives the timeout and the query is (this is MariaDB 10.11) - our current production version:

SELECT  log_id,log_type,log_action,log_timestamp,log_deleted  FROM `logging` JOIN `actor` ON ((actor_id=log_actor))   WHERE (log_type NOT IN ('spamblacklist','titleblacklist','urlshortener','abusefilterprivatedetails','abusefilterblockeddomainhit','abusefilter-protected-vars','oath','checkuser-temporary-account','checkuser-private-event','ipinfo','suppress')) AND actor_name = 'DGG' AND ((log_deleted & 4) != 4)  ORDER BY log_timestamp DESC,log_id DESC LIMIT 2

@Anomie gives a query against the real tables in T71222#742492, though that's now very out of date (actor table, at minimum).

I've tried a few times the URLs on the task description but they seem to work to me, any chances anyone has the query handy so I can test on the prompt?

@Draceane: Thanks for reporting this. For future reference, please use the feature request form (linked from the top of the task creation page) to create feature requests, and fill in all the sections in the template. Thanks.

Adding a fresh stack trace here for searchability:

In T407582#11293335, @Marostegui wrote:

What do we want to do with this task then?

What do we want to do with this task then?