This was an interesting bug, which was causing SHAs to change mysteriously across serialization/deserialization.
The "match" for addBytes() has two cases for Traversable and for Product; the case for Product was listed first. However, it just so happens that the default Seq is a List, and therefore the majority of sequences in the system are Lists. And a List is actually a Product, of respectively head and tail.
As a consequence, each time a List was included in a SHA calculation, only the Product case was used. However, when a Seq was the result of some other mapping leading to a WrappedArray, or an ArrayBuffer, the Traversable code path was chosen instead, leading to seemingly inexplicable situations in which working code would no longer work on serialized/deserialized data, which would transform for instance an ArrayBuffer into a List containing the same data.
Just swapping the two case clauses fixes the problem, and allows us to have a stable SHA calculation for all sequences.
jsuereth
commented
10 years ago
This was an interesting bug, which was causing SHAs to change mysteriously across serialization/deserialization.
The "match" for addBytes() has two cases for Traversable and for Product; the case for Product was listed first. However, it just so happens that the default Seq is a List, and therefore the majority of sequences in the system are Lists. And a List is actually a Product, of respectively head and tail.
As a consequence, each time a List was included in a SHA calculation, only the Product case was used. However, when a Seq was the result of some other mapping leading to a WrappedArray, or an ArrayBuffer, the Traversable code path was chosen instead, leading to seemingly inexplicable situations in which working code would no longer work on serialized/deserialized data, which would transform for instance an ArrayBuffer into a List containing the same data.
Just swapping the two case clauses fixes the problem, and allows us to have a stable SHA calculation for all sequences.