uuid: Fail under Windows 10 x64
After converting my own project into go.mod and run go test all under module root, got:
--- FAIL: TestGenerator (0.02s)
--- FAIL: TestGenerator/NewV2 (0.00s)
--- FAIL: TestGenerator/NewV2/DifferentAcrossCalls (0.00s)
generator_test.go:210: generated identical UUIDs across calls: 3912a521-2f04-21e9-8002-309c238cfc62
FAIL
FAIL github.com/gofrs/uuid 0.757s
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 15 (11 by maintainers)
Commits related to this issue
- Update V2 test to use delay to guarantee unique UUID generation This change updates the uniqueness test for the `NewV2()` function to have a sleep delay between the two generations of the UUID. This ... — committed to gofrs/uuid by theckman 5 years ago
- Update V2 test to use delay to guarantee unique UUID generation This change updates the uniqueness test for the `NewV2()` function to have a sleep delay between the two generations of the UUID. This ... — committed to gofrs/uuid by theckman 5 years ago
- Update V2 test to use delay to guarantee unique UUID generation This change updates the uniqueness test for the `NewV2()` function to have a sleep delay between the two generations of the UUID. This ... — committed to gofrs/uuid by theckman 5 years ago
- Update V2 test to use delay to guarantee unique UUID generation This change updates the uniqueness test for the `NewV2()` function to have a sleep hop between the two generations of the UUID. This sh... — committed to gofrs/uuid by theckman 5 years ago
- Update V2 test to use delay to guarantee unique UUID generation This change updates the uniqueness test for the `NewV2()` function to have a time hop between the two generations of the UUID. This sho... — committed to gofrs/uuid by theckman 5 years ago
@wtask I’ve figured out why this is failing, and it’s pretty great. Your system is running the tests too fast.
In the test that failed we pass in
uuid.DomainOrgas thedomainto theNewV2function. When you useDomainOrgthe UUID generation code does not overwrite the timestamp field on the UUID. The Timestamp itself is a 60-bit unsigned integer, that is the number of 100-nanosecond increments since some epoch value in the 1500s.So if you are able to generate two UUIDs within the same 100ns bucket of time, this test will fail. If your system is slower, like I suspect TravisCI to be, the tests will pass just fine. So I think the fix would be to underclock your workstation. 😉
All jokes aside, it’s an interesting side effect. I think pursuing a fix similar to what we did in #70, but with a tighter timeframe, makes sense.
Isn’t uid/gid just first 4 bytes and the rest still should be “random” (bytes 4-8 are comprised of current time which is guaranteed to be unique)?
Oh, byte 9 is supposed to provide that uniqueness is overwritten by the domain 😒
Wikipedia: