1333874 - mergeUpdate is broken when a base table row updates a value to the same value in the scheduled change

Status: RESOLVED FIXED

(Release Engineering Graveyard :: Applications: Balrog (backend), defect, P1)

Description

[[e-mail] (:bhearsum)]

When someone tries to update an object that has an active Scheduled Change, we try to detect collisions by performing a 3 way merge on the current version of the object, the scheduled change version, and the requested update. If the scheduled change and requested update are both modifying the same column, we cannot make the requested update because it would invalidate the scheduled change.

It looks like this check is broken when the scheduled change and requested update are changing the same column to the same value. An interesting side effect of this is that it means that any future updates to that object (until the scheduled change is enacted) will always merge over to the scheduled change.

I had a look at the code, and it looks like we're comparing the requested update to the scheduled change instead of the current version of the object. The comment at https://github.com/mozilla/balrog/blob/3a0bbff051c7bcecdb6efd672bca6c26266e07c4/auslib/db.py#L1214 reads like we wanted to comparing the requested update to the current version of the object, which matches what it's in my head too. In a 3 way merge, that current version of the object is the "base" - not the scheduled change.

I tried changing that line to compare the current object and the requested version, and all of the tests still pass, so I suspect that's the fix here. We'll need a test for this case too, and some manual verification would be good as well.

Comment 1

[[github robot]]

Commit pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/ac29e19c2d3e4f29af74296d03c908f0ff32320b
Bug 1333874: mergeUpdate is broken when a base table row updates a value to the same value in the scheduled change (#245). r=bhearsum

Comment 2

[[e-mail] (:bhearsum)]

This is in production. Thanks a lot for your contribution Matt!