One general fix would be to abandon Serializable entirely. A trait like this should give basically the same functionality without the bug:

trait WorkingSerializable {
    protected $serializeData = null;

    /**
     * Return serialization data
     * @warning Don't call PHP's `serialize()` from this method!
     * @return array
     */
    abstract protected function serialize();

    /**
     * Restore state from serialization data
     * @param array $data
     */
    abstract protected function unserialize( array $data );

    public function __sleep() {
        $this->serializeData = $this->serialize();
        return [ 'serializeData' ];
    }

    public function __wakeup() {
        $this->unserialize( $this->serializeData );
        $this->serializeData = null;
    }
}

Another possible fix, that might also bring some benefit towards T161647: RFC: Deprecate using php serialization inside MediaWiki, would be to write our own serializer that will only serialize/unserialize bare stdClass and objects implementing an interface with methods like the abstract methods on that WorkingSerializable trait.

OTOH, retrofitting that onto everything that currently uses serialize() would be quite a bit of work.

In T210528#4778665, @Anomie wrote:

One general fix would be to abandon Serializable entirely.

There are few cases of using Serializable in libraries (though it looked as if most/all were under our control): https://codesearch.wmflabs.org/deployed/?q=Serializable&i=nope&files=&repos=

I'm not sure if we should invest that much effort for HHVM compat fixes (mostly updating everything to use WorkingSerialize until we drop HHVM support, and then reverting it all), we could also:

• Add some extra suffix/prefix for PHP 7 cache keys so they don't use the same cache, which avoids any other case of caching/serialization formats between HHVM and PHP being incompatible.
• Apply the PHP patch to our HHVM build (I have no idea how trivial or complicated that is)

Change 476280 had a related patch set uploaded (by Anomie; owner: Anomie):
[operations/mediawiki-config@master] Avoid putting Message objects in sidebar cache

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

Change 476287 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] Message: Don't include Title objects in the serialization (part 1)

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

Change 476288 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] Message: Don't include Title objects in the serialization (part 2)

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

Change 476289 had a related patch set uploaded (by Anomie; owner: Anomie):
[mediawiki/core@master] Message: Throw if given invalid serialized data

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

Change 476287 merged by jenkins-bot:
[mediawiki/core@master] Message: Don't include Title objects in the serialization (part 1)

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

Change 476289 merged by jenkins-bot:
[mediawiki/core@master] Message: Throw if given invalid serialized data

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

Change 476280 merged by jenkins-bot:
[operations/mediawiki-config@master] Avoid putting Message objects in sidebar cache

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

Mentioned in SAL (#wikimedia-operations) [2018-12-03T18:42:21Z] <anomie@deploy1001> Synchronized wmf-config/CommonSettings.php: Updating SkinBuildSidebar hook function for T210528 (duration: 00m 47s)

Is this still unresolved? If so, it should be marked as a blocker to the php7 transition. @Anomie do you think there is anything else left to do?

We've worked around it for the sidebar and for Message objects' ->title attribute generally, and added a check so Message will throw an exception rather than continue execution with broken state if it occurs in some other part of the serialized state. But it's possible a similar situation could occur with other classes implementing Serializable if their serialized data contains references.

The decision above seems to be that we'll know that log messages like "Unable to serialize r:46: Id 46 out of range." signal that this issue is occurring and deal with it if it actually happens, rather than trying to preemptively find and replace all uses of recursive serialization in the Serializable interface.

I suppose if someone wanted to be a little preemptive they could go through those other classes to add checks like rMWe2f2da74f2fc: Message: Throw if given invalid serialized data or otherwise verify that things won't break if the recursive unserialize() call returns false.

Change 476288 merged by jenkins-bot:
[mediawiki/core@master] Message: Don't include Title objects in the serialization (part 2)

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

Current status: The known problems with the Message class have been worked around in various ways. It's possible that other classes using Serializable might still run into the same problem. Watch for log messages like "Unable to serialize r:46: Id 46 out of range.".

I'm marking this with Platform Team Workboards (Done with CPT) for now, although it could move back if we find other things hitting this issue. I don't know whether we should resolve this now (and reopen it if other things hit it, or track "mitigate T210528 in X" as new tasks), or if we should just leave this open until HHVM is gone.