Different received result on CI vs development

[benmccallum]

Have this strange issue on CI (TeamCity) whereby it's getting a different received result.

The difference is subtle, but essentially it's the first two properties being swapped around.

Have run CI twice and both times got the same result.

I briefly went down the upgrade to v17 path, to see if that helped. #533 was ok, but #526 is a bit of a painful one. So I've had to bail on that for now and thought I'd throw the question out there.

Environments

Development

.NET SDK: 6.0.400
Verify.Xunit version: 16.8.2

CI

.NET SDK: 6.0.100 <--------------- different I guess... edit: updated to .400 and didn't help
Verify.Xunit version: 16.8.2

Diff

CI gets:

{
  BookingStatusID: Id_1,
  OriginalSupplierId: Id_2,
  StatusAt: DateTimeOffset_1,
  //...
}

Development myself and team mate get:

{
  OriginalSupplierId: Id_1,
  BookingStatusID: Id_2,
  StatusAt: DateTimeOffset_1,
  //...
}

[SimonCropp]

re the numeric id. we could add it back as an opt in feature

re the order of props. can u share the class file that contains those properties?

[SimonCropp]

does BookingID and/or OriginalSupplierId exist as props on the interfaces?

[benmccallum]

Id vs ID suffix sticks out. Might be time to finally crush the inconsistency

[SimonCropp]

either way BookingID should be first. so u can debug into verify to see what the problem is

[benmccallum]

In this particular test its not a full integration test, so BookingID is 0 and doesn't render out.

But OriginalSupplierId should come before BookingStatusID I'd imagine.

[benmccallum]

BookingStatusID is in a region, but surely that has no real impact :P

[benmccallum]

Gave 16.9.0 a crack and that seemed to work.
Diff seems pretty minimal, but might've been enough? 16.8.2...16.9.0

[benmccallum]

Could also be the fourth run is the charm, but I doubt it. 2 runs on same versions of everything, 3rd run on latest net sdk, 4th with bumped verify.xunit.

if it crops up again on v17 when I get there I'll investigate further. Thanks anyway :)

[SimonCropp]

on the numeric id. the idea behind the guid/date scrubbers is that the replace with the same value. so if the replacement is the same, u can assume they represent the same thing. that simple isn’t the the case with numeric ids. u can have two unrelated entities, both incrementing ids, that happen to get the same number and get replaces with Id_x. which misleads the user