v7: passing `options.msecs` results in zero-value timestamp about uuid HOT 5 CLOSED

I created a PR that fixes the main issue.

Should IDs generated with user-supplied options read / mutate internal state at all?

We should support generation of multiple UUIDs within the same millisecond that was user-provided. Ideally with monotonicity. One example is backfilling. Current time is then treated as a default and does not have a special treating.

One unsolved (and probably unsolvable) case is when the the function is called by alternating timestamps. Then each time it's treated as the first and monotonicity is lost. I can imagine this can happen as this library is quite popular so multiple sources can call it simultaneously. I wrote about this in the original PR (point 5): #681 (comment)

from uuid.

@pmccarren

from uuid.

@pmccarren I've confirmed this is an issue. I think this occurs because the timestamp field is set from the internal _msecs value, which is initialized to zero. And passing options.msecs triggers this code path which doesn't update _msecs to the user-provided value.

Can you take a look?

from uuid.

TL;DR: Providing any custom msecs results in a wrong UUID.

Looking at the code, this is much deeper issue with any user-provided msecs. It is essentially treated as a replacement of the system clock and so its value is compared to previous runs and it is stored for the future runs.

So if you run it first without custom msecs, it will remember the current time and reject any later msecs that is sufficently in the past or in the future. It will also not reset the random part properly.

See this sequence:

> v7({msecs: Date.UTC(2022)})
'00000000-0000-755b-b297-8ed274801af9'
// Wrong
> v7()
'019016b9-1098-755b-b297-9502eecb44e3'
// Correct time, seq_high unchaged
> v7({msecs: Date.UTC(2022)})
'017e12ef-9c00-755b-b297-94f2d59d9a23'
// Correct time, seq_high unchaged
> v7({msecs: Date.UTC(2028)})
'017e12ef-9c00-755b-b297-98a0301b8a02'
// Wrong time! Uses previous timestamp. seq_high unchaged
> v7()
'019016b9-4fe0-755b-b297-a148d28e3621'
// Correct time, seq_high unchaged

Problems

1. Until the first call without a custom timestamp, no custom msecs will work at all.
2. After a call with no timestamp, it's possible provide custom msecs in the past. However, it's impossible to move to a future from the last run. It's only possible to reset to now with a no custom timestamp call.
3. The seq_high (755b-b297 in the calls above) is not changed among calls.

I believe this has a high severity and we should take an immediate action, @broofa and @pmccarren

I'm writing a test for this in my fork, see here: robinpokorny@9eb076a

from uuid.

@robinpokorny All good points, and thanks for putting that test together.

This does raise a couple questions that I don't have good answers to at the moment:

Should IDs generated with user-supplied options read / mutate internal state at all?

It's been a good while since I gave any thought to this aspect of the uuid API. At the moment, I'm of the mind that allowing calls with user-specified options to read or write internal state is probably a bad idea in general. Certainly modifying internal state based on user-supplied options risks destabilizing code that may not be expecting that. And relying on internal state means we can't insure idempotent behavior, which makes writing test code difficult.

Where user-provided options overlap with internal state, do they represent the state prior to UUID generation or the state reflected in the generated UUID?
E.g. If a user passes options.seq: 0, is that the initial or final value of seq after the uuid has been generated? Basically uuid generation (at least where v1 and v7) is concerned has two parts: updating the internal state, and then generating the uuid from that state. If the user supplies options, are they specifying internal state values before or after the update step?

from uuid.