Only happens on fiwiki because they have some automated process in place which scrapes AbuseLog entries and often comes across broken entries. In short, the error happens because in the past we used to store in the DB serialized instances of AFComputedVariable, which in turns includes instances of Revision etc (scary, right?). The Revision class has changed since then, and the error pops out. The proper solution is a maintenance script as devised in T213006, which in turn is blocked (at least) on T34478 and T213478. A hack was put in place at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/502946/, but apparently that's not enough.

Looking at the stacktrace and at the amount of errors on fiwiki, I'm still convinced that it's a duplicate of T187153. At any rate, we're gonna prove or disprove it once https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/AbuseFilter/+/510725/ hits production in wmf.6.

I do not know much about MediaWiki nowadays, but the fault is in WikiPage::loadFromRow( $data, $from ) which, when given $data does:

573             // T39225: $latest may no longer match the cached latest Revision object.
574             // Double-check the ID of any cached latest Revision object for consistency.
575             if ( $this->mLastRevision && $this->mLastRevision->getId() != $this->mLatest ) {
576                 $this->mLastRevision = null;
577                 $this->mTimestamp = '';
578             }

Which leads to /srv/mediawiki/php-1.34.0-wmf.5/includes/Revision.php:639:

633     /**
634      * Get revision ID
635      *
636      * @return int|null
637      */
638     public function getId() {
639         return $this->mRecord->getId();
640     }

And mRecord is null somehow :-(

In T223447#5197319, @hashar wrote:

And mRecord is null somehow :-(

That is very strange, and should not be possible at all...

Have you seen T187153? If it's the same issue (and I think it is), mRecord is null because there's a Revision object serialized and stuffed into the DB which could be 10 years old now, it's pretty obvious that unserializing and using it is not going to work...

In T223447#5198110, @Daimona wrote:

Have you seen T187153? If it's the same issue (and I think it is), mRecord is null because there's a Revision object serialized and stuffed into the DB which could be 10 years old now, it's pretty obvious that unserializing and using it is not going to work...

Eeeek. We should probably not even try to unserialize them!

In T223447#5198138, @daniel wrote:

In T223447#5198110, @Daimona wrote:

Have you seen T187153? If it's the same issue (and I think it is), mRecord is null because there's a Revision object serialized and stuffed into the DB which could be 10 years old now, it's pretty obvious that unserializing and using it is not going to work...

Eeeek. We should probably not even try to unserialize them!

Heh, that's asking too much :-) As I said in T223447#5186965, there are plans to get rid of them, but the process is currently stalled. I was waiting for input on T34478 and T213478 before moving on.

In T223447#5209760, @Daimona wrote:

As expected, this was fixed by the patch for T187153, which landed in production yesterday with wmf.6 at 13:22UTC. The error rate dropped from ~475/30 mins to a flat 0 at that time.

Perfect!! Thank you for the house keeping :]]]]