Auto UUID creation seems improper? Existing docs getting overwritten even with insert operation

[regstuff]

Bug Description:

When adding new documents into a table and using the auto UUID feature, manticore seems to be generating UUIDs that already exist in the table and is therefore rewriting documents.
I am unable to give an exact situation and MRE but I am noticing this in some of my tables.

For example, I wrote a list of all ids in a table named gnanetra into a txt file first. There are around 47050 ids. Here is a sample of those:

1677721603112, 1677721600184, 1677721603113, 1677721600454

There are many more, but I have included 1677721600184 from the list because when I insert a new doc as below, the new doc gets 1677721600184 assigned as its id, and the original doc is replaced, though I have done an insert.
Also the id seems to start at 1677721600000 for any new index (irrespective of when the server started) and on different machines as well, which is a bit odd as I thought UUID uses the timestamp of server start as part of its string.

1677721600000 is the timestamp of 2 March 2023, which is pretty close to the release of version 6.0.2(??)

resp = indexApi.insert({"index" : "gnanetra", "id":0, "doc" : doc})
print(resp)

Prints out:

{'created': True,
 'found': None,
 'id': 1677721600184,
 'index': 'gnanetra',
 'result': 'created'}

This happens with or without forcing id to 0. Python client version is 4.0

Manticore Search Version:

6.3.0

Operating System Version:

Windows 11 & Windows Server 2013

Have you tried the latest development version?

None

Internal Checklist:

^{To be completed by the assignee. Check off tasks that have been completed or are not applicable.}

Details

• Implementation completed
• Tests developed
• Documentation updated
• Documentation reviewed
• Changelog updated

[sanikolaev]

The related forum topic is https://forum.manticoresearch.com/t/auto-uuid-creation-seems-improper-existing-docs-getting-overwritten-even-with-insert-operation/2005/4

I can't reproduce it in Linux / Mac, but the ids there are much longer. @tomatolog pls try reproducing in Windows.

[tomatolog]

I can not reproduce issue at Windows 10 or Windows 11 with Manticore search 6.3.0 release.
After I started daemon I issue

mysql> drop table if exists t; create table t; insert into t values(0); select * from t;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

Query OK, 1 row affected (0.00 sec)

+---------------------+
| id                  |
+---------------------+
| 1011553662943625217 |
+---------------------+
1 row in set (0.00 sec)
--- 1 out of 1 results in 0ms ---

then I restarted daemon and could insert new documents without replacing the old document

mysql> insert into t values(0); select * from t;
Query OK, 1 row affected (0.00 sec)

+---------------------+
| id                  |
+---------------------+
| 1011553663245615105 |
| 1011553662943625217 |
+---------------------+
2 rows in set (0.00 sec)

even if I recreate table I still see the new doc id

mysql> drop table if exists t; create table t; insert into t values(0); select * from t;
Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

Query OK, 1 row affected (0.00 sec)

+---------------------+
| id                  |
+---------------------+
| 1011553663245615106 |
+---------------------+
1 row in set (0.00 sec)

could you check that you do not start daemon with --test cli?
create you create MRE that reproduces issue locally and provide all files?