Hi Eric:

I'm glad to hear that the general behavior of your naming pattern is now as expected; that's what I can reproduce locally as well with that pattern.
As far as reasons a sample might exist with that higher counter value, there are a few possible explanations:

1. It's possible to provide a name during sample creation so that the pattern is not used, so if the name ending in _101 was typed or provided via file import with that 'typo', it could look the same as others of that series but not have been generated with the :withCounter modifier.

2. The "MaterialIputs:first" element means the first sample parent, and because no sample type or property name is provided, the system will assume you mean the SampleID. In a case of more complex lineage or multiple parents (or multiple generations of parents of different types) it's possible that the parent selected as 'first' had more generated samples - you could tell that perhaps by looking at the full generated name (as well as the lineage of that sample).
   If you have a situation where parents are of different types, and you want to use the name of the parent of a specific type, you can increase the specificity of that naming pattern by using "MaterialInputs/SampleType/SampleID:first" (or similar).

3. It may be the case that a large generation of samples was begun but cancelled, still 'reserving' the missing counter numbers, though that seems unlikely as it sounds like the sequence did not continue with 102, 103, etc. but the next generated ones were back in double digits.

4. Another possibility, though unlikely, is that there was a different naming pattern in force when the _101 sample was generated. When the pattern is edited, the already existing names are not changed, so this could also explain what you saw.

There is additional documentation about naming patterns available in two topics, depending on which product you are using:

• LabKey Server: Sample Naming Patterns
• Sample Manager: Sample Naming Patterns

Hopefully that's helpful,

--Molly

Hi Eric,
Correction to my previous comment - unfortunately, this issue has not been addressed. Since the likely culprit is as Molly described in #3 due to a server crashing, I'd recommend keeping an eye out for aliquots created post crash and changing those manually at this time.
Regards,
Hannah