MariaDB [enwiki_p]> SELECT page_id, page_namespace, page_title FROM enwiki_p.page where page_id IN (50274778,1272531,976991,50274777) ORDER by page_namespace;
+----------+----------------+--------------------+
| page_id  | page_namespace | page_title         |
+----------+----------------+--------------------+
|   976991 |              0 | Orchard,_Singapore |
| 50274777 |              0 | Orchard,_Singapore |
|  1272531 |              1 | Orchard,_Singapore |
| 50274778 |              1 | Orchard,_Singapore |
+----------+----------------+--------------------+
4 rows in set (0.01 sec)

Yowza.

The enwiki database has drifted from production (see T133715: Missing data on labs replica database, T134203: enwiki_p replica on s1 is corrupted).

After seeing many cases like this, I can conclude that replication to labs breaks whenever there is a page move, an archival or an undeletion. I have not yet clear why, but given that it only happens on labs, it is probably due to running insecure statements that break on filtering, or due to the filtering itself.

If the first case, that could be solved by switching to row based replication (which is planned, but not something that will happen immediately because it involves production, and it is not easy). If the second case, it may be even more difficult, or logically impossible (if things should be sanitized due to them containing private data and at the same time queries are done based on sanitized data, things will eventually drift sooner or later).

I think the more immediate way to solve this would be to finish the resync, hope that the final state will be 99% consistent, and then setup a process that monitors and fixes the differences until the root cause is analyzed and fixed (if that is possible).

Of course, I can fix individual reports, although we should setup a more convenient way than a ticket per row with problems.