IndexOutOfRangeException from BetterCache in UUIDNext

[tim-basic-fit]

I am seeing some incidental hard-to-reproduce exceptions being thrown from my backend from the UUIDNext library. I have a lot of instances running, with heavy threading/tasks, so it might be something related to thread-safety. I did see locking around BetterCache, so it looks like it's supposed to be threadsafe.

I am replacing the UUID generation with the new .NET 10 version (Guid.CreateVersion7), but I thought I'd pass this error on, there might be some issues in the BetterCache implementation.

Code:

Guid id = UUIDNext.Tools.UuidToolkit.CreateUuidV7FromSpecificDate(dateTime);

Stacktrace:

[
{"assembly":"System.Private.CoreLib, Version=10.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e","method":"Internal.Runtime.CompilerHelpers.ThrowHelpers.ThrowIndexOutOfRangeException","level":0,"line":0},
{"assembly":"UUIDNext, Version=4.2.2.0, Culture=neutral, PublicKeyToken=21e3efdd005d67ea","method":"UUIDNext.Tools.BetterCache`2.AddOrUpdate","level":1,"line":0},
{"assembly":"UUIDNext, Version=4.2.2.0, Culture=neutral, PublicKeyToken=21e3efdd005d67ea","method":"UUIDNext.Generator.UuidFromSpecificDateGeneratorBase.New","level":2,"line":0}
]

[mareek]

Thank you for reporting the issue.
It is indeed really strange. I've run some stress tests on my laptop to try to reproduce the exception without success.

By curiosity, why are you using UuidToolkit.CreateUuidV7FromSpecificDate(dateTime) and not Uuid.NewSequential() ?

[mareek]

I finally managed to reproduce your bug; it's indeed a concurrency issue.

Unfortunately, I need to generate tens of thousands of UUID in parallel to reproduce the bug consistently so it won't be easy to debug.
I will try to look at it more thoroughly this week

[tim-basic-fit]

By curiosity, why are you using UuidToolkit.CreateUuidV7FromSpecificDate(dateTime) and not Uuid.NewSequential() ?

NewSequential doesn't have an overload with a datetime. I generate events at an earlier point in the pipeline. At some point, they might get sent if conditions are met, and then I generate an identifier. The identifier for the event has to use the event timestamp, NOT the current timestamp. Hence I'm using the overload.

It could very well be the case that a couple of servers have RAM issues, only saw the issue for about 0.5% of the instances.

[mareek]

I've finally found the bug !
It's not a concurrency problem nor a RAM issue, just a bug that only happens in a very specific and rare situation.

I've merged the fix and I'll publish a new version later this week.

Thanks again fore reporting the issue