Wikimedia Bugzilla is closed!

SnakUnserializer will check the hash of the unserialized snak against the snak field in the serialization, and fails if they are not equal. The fail-fast approach is counter to the need to be able to read old or seemingly corrupt data.

There are two critical cases:

1) the value type used in the snak is not configured on the local system. The value would then unserialize into a UnDeserializableValue object, which would round-trip cleanly - but with the hash check, the unserialization is aborted.

2) the structure of the snak or value class changes a bit (e.g. we decide to add a field, or apply additional normalization). Even if the unserialization is backward compatible, we would still fail because the hash is now different.

Number (2) is especially bad because getHash() is implemented as sha1( serialize( $this ) ). This uses php's internal serialization, not SnakObject::serialize - so it would change even if we just re-arrange the members in a class, or rename a private field. If we change this to sha1( serialize( $this->serialize() ) ), we would have more control, but could still never add or re-arrange fields.

So, in order to be able to read legacy data, SnakUnserializer must not be picky about the hash. Perhaps an SerializationErrorMonitor of some sort could be injected to decide whether to ignore the problem, log it, or throw an exception, depending on the needs of the respective use case.