Also, what does 5/8/21 relate to? Vendr's default order numbers are in a format like ORDER-0379-0928-MYKK If your order numbers don't look like this, then it sounds like you are using a custom order number generator.

Sorry 5/8/21 is a date 5 Aug. That was the last time this happened

Gotcha. Did you see my other questions?

Yes I did. Just looking at the records now... please hold :)

Thanks for taking the time to reply Matt.

Was wrong in fact, we have had a few occurrences in Aug and the latest was today (12 Aug).

So lets just look at August.

One occurrence on each of the following days - 4, 5, 6, 8 and 12 Aug.

No discernible pattern in the time of day.

Each duplicate is created from between 1.5 minutes and 19.5 minutes after the original.

Yes the site is load balanced. I'll see if we can get more info about load from Azure.

Jules

Hi Matt

Actually I've been comparing the createDate on the order table.

I notice there is updateDate and finalizedDate. At what point is the orderNumber generated?

Jules

Hmm, actually I guess it's more when they hit the review stage of the checkout as that is when the order number is generated, but unfortunately we don't store an "OrderNumberGeneratedDate" so I don't think we are going to be able to deduce this.

So our default order number generator is date based, the format is ultimately

ORDER-{1}-{2}-{3}

• {1} = Number of days diff between Now and 01/01/2020
• {2} = Number of minutes + (hours * 60) diff between Now and 01/01/2020
• {3} = Number of seconds diff between Now and 01/01/2020 + (internal static counter * 60, wrapping at 97) hashed using Hashids

I have spotted a problem with this setup that I think could be the culprit, and that is, if the order numbers are generated at the exact same second, and the environment is load balanced, then there is the possibility that in {3} the static counter which should prevent duplicates within the same second could be the same (it's a static counter so it's only unique per instance).

One thing I have just thought to do, which I think should reduce the liklihood of a duplicate significantly is, the Hashid function used in {3} takes a salt for the hash, which is currently a hard coded GUID, but we do have Constant.InstanceId which is a static GUID that is generated when the app domain for that instance starts up, and thus unique per instance, that we could potentially use as the salt and so if there are multiple instances running, even if their static counters are the same, the Constant.InstanceId GUID's would be different and so they would be using a different salt to generate the hash.

This may all sound overkill for order number generation, but when we did early load testing, if we had an order number generation strategy that needed to hit the database to know what the next number was, ie if we did sequential order numbers, this was a HUGE bottleneck, so the aim of the default order number generator is to create unique order numbers in a way that doesn't require any other resources.

With the above change, there is still the remote possibility of a duplicate hash being generated, but from my calculations it's a 1 in 700,000 chance, compounded with the fact they would still requiring that the order number must be generated at the same exact second.

Matt

UPDATE With a small tweak, I can actually get it to a 1 in 810,000 chance 😁

Given you are on a beta build I'm guessing you already have access to our unstable feed. If you do, there should be a new 1.8.6-beta build with these changes applied so if you wanted to upgrade to that early, you can.