Hash diffing algorithm is incorrect in certain cases

[khiav223577]

See the screenshot:

This is the test cases:

it do
  expect_response_header(:ok)
  expect(response_data).to eq(
    "items_count" => 2,
    "max_page"    => 2,
    "elements"    => [
      {
        "id"                        => target_specimens[0].id,
        "kind"                      => "lithium_heparin",
        "number"                    => "107-HEP-0001",
        "patient_medical_record_no" => "MED_0077",
        "patient_name"              => nil,
        "patient_id_card"           => nil,
        "patient_gender"            => nil,
        "patient_birthday"          => "1991-03-12",
        "patient_hospital"          => nil,
        "family_hospital"           => nil,
        "family_medical_record_no"  => nil,
        "family_title"              => nil,
        "inspect_date"              => nil,
        "submit_date"               => nil,
        "receive_date"              => "2017-06-01",
        "inspection_unit"           => nil,
        "inspection_doctor"         => nil,
        "description"               => nil,
        "disease"                   => nil,
        "REQ"                       => nil,
        "comments"                  => nil,
        "discarded_at"              => "2018-07-03 08:12:54"
      }
    ]
  )
end

Environment

super_diff (0.5.2)
ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-linux]
Rails 5.2.4

[mcmire]

Thanks for the report, that's weird for sure. I'll check it out shortly!

[jas14]

I have another repro case where the diff is missing keys:

expected = {
  a: 1,
  b: 2,
  c: 3,
}
actual = {
  c: 1,
  b: 2,
  a: 3,
}
puts SuperDiff.diff(expected, actual)

yields:

  {
+   c: 1,
    b: 2,
-   c: 3
+   a: 3
  }

In this example, c is correctly changed, and b is correctly a no-op, but a is added (per expected) without removal from actual.

[jas14]

I've bisected this to 3387189, first included in v0.5.0, which was released on Jun 18, 2020. Makes sense with the large change to the hash differ.

I'd like to work out how to fix the existing algorithm, but it's complex – it may take me a while. In the meantime, reverting to the older algorithm is an option – it doesn't attempt to preserve the order of the keys in the expected hash, but is correct.

[jas14]

A fix for this bug was released in v0.17.0.