I think this is the top timing out query right now, on top of the usually bad combinations of recentchanges, at least for Wikidata- which is pathological because of the number of contributions a single page can have:
If this is due to a deployment, a bot changing query patterns or a data change, is yet to see. One example of the query that fails is:
SELECT rev_id,rev_page,rev_text_id,rev_timestamp,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,COALESCE( comment_rev_comment.comment_text, rev_comment ) AS `rev_comment_text`,comment_rev_comment.comment_data AS `rev_comment_data`,comment_rev_comment.comment_id AS `rev_comment_cid`,rev_user,rev_user_text,NULL AS `rev_actor`,rev_content_format,rev_content_model,page_namespace,page_title,page_id,page_latest,page_is_redirect,page_len,user_name,page_is_new,(SELECT GROUP_CONCAT(ct_tag SEPARATOR ',') FROM `change_tag` WHERE ct_rev_id=rev_id ) AS `ts_tags`,ores_damaging_cls.oresc_probability AS `ores_damaging_score`,0.412 AS `ores_damaging_threshold` FROM `revision` LEFT JOIN `revision_comment_temp` `temp_rev_comment` ON ((temp_rev_comment.revcomment_rev = rev_id)) LEFT JOIN `comment` `comment_rev_comment` ON ((comment_rev_comment.comment_id = temp_rev_comment.revcomment_comment_id)) INNER JOIN `page` ON ((page_id = rev_page)) LEFT JOIN `user` ON ((rev_user != 0) AND (user_id = rev_user)) LEFT JOIN `ores_classification` `ores_damaging_cls` ON (ores_damaging_cls.oresc_model = '9' AND (ores_damaging_cls.oresc_rev=rev_id) AND ores_damaging_cls.oresc_class = '1') WHERE ((rev_user = '2752938')) AND (rev_parent_id = 0) AND (page_namespace = '0') AND ((rev_deleted & 4) = 0) ORDER BY rev_timestamp DESC LIMIT 51
Running on the 'contributor' special partitioned replicas.
I don't think this is urgent because the number of errors is relatively low, although constant, but it is worth at least checking why it happens. I found T47619, probably not relevant because how old it is, except for the latest changes and decisions the query suffered.