A cautionary tale - mgo asserts

[roger peppe]

On 8 June 2016 at 10:05, Tim Penhey <tim.penhey at canonical.com> wrote:
> Hi folks,
>
> tl;dr: not use structs in transaction asserts
>
> I have spent the last two days looking at this bug:
> https://bugs.launchpad.net/juju-core/+bug/1537585
>
> It was one where the instance poller got itself in a knot, and couldn't get
> out. Transaction asserts were failing, and often hard to reproduce.
>
> Nate spent last week on it, and I pulled Menno in for his mgo expertise
> yesterday and today because I was getting stumped.
>
> Here is what was happening:
>
> The machine document was being read, and we were wanting to update the
> preferred public and private addresses. An assert was added to make sure
> that the value was either what we expected it to be (from reading the doc),
> or unset. Now, really, it wouldn't be unset, but that is a different story.
>
> The problem is that the assert was failing. Logging was added to check what
> the db had, and what the asserts were transformed to with the multi model
> layer. All the asserts matched. The data was there, everything was good,
> except it wasn't.
>
> This morning, I pulled the data out with a bson.D, and it became readily
> apparent that the address structure ordering was different in the times it
> failed. Now normally we are guaranteed ordering. When the struct is
> marshalled to bson, it is as a bson.D with the order defined in by the order
> of the members.  However when using the struct in the assert, it was
> matching different orders, so the assert failed.

This is interesting and not something I was aware of. I had been under
the impression that bson.D could almost always be used interchangeably
with bson.M or structs and that key order wasn't relevant when comparing
objects.

Could you provide a simple example (preferably not involving mgo/txn)
where the results are different depending on member ordering?

  cheers,
    rog.