Beware of depending on subtle differences in result orders from the Data Modelling API

If you have tests that assume the a specific result ordering in instance list or query results without specifying a sort order when querying for recently upserted nodes, you may in the future see that APIs can return results in a different order than they were upserted, and possibly see your tests fail.

The change in ordering happens when we insert data in the DM graph, and is required to make sure we correctly serialise operations and avoid deadlocks when processing upsert operations. The previous implementation is prone to rare race conditions that, while not having been a frequent problem before, may become a problem now as we work to optimize DM API performance and add support for more sophisticated access control in instance upsert operations.

While this change is observable if your test hard codes an assumption that items are returned in the same order that they were inserted, this behavior was never specified, let alone guaranteed. The API behavior remains in line with previously documented behavior.

The set of returned instances remains the exact same as before, you may just see them in a different order because we process the write operation in a more robust way. Tests that depend on this behavior should be updated to fix this assumption, such as by adding a sort on a stable property such as externalid, or perform a set comparison rather than list comparison.

If you see your tests failing because the DMS API result isn't quite matching what you expect, this may explain things.