LiteDB.LiteException: 'Cannot insert duplicate key in unique index '_id'. The duplicate value is '290'.'

I’m reporting this without a full understanding of the sequence of events which led to this condition so that it is captured. If it happens again I will back-fill with further detail.

The situation I encountered today with LiteDB (version 4.1.4) was inserting a record without setting the value of the Id field into a specific document collection started failing.

The code path for this insert hadn’t changed in over 5 months, but inserting into one specific Collection in the LiteDB database stopped working earlier today. Calls to LiteCollection<T>.Insert(T document) started throwing the cited exception: LiteDB.LiteException: 'Cannot insert duplicate key in unique index '_id'. The duplicate value is '290'.'

For the document which was being inserted, the Id field was not specified so the document should have been inserted with an auto incremented value in the id field by the database engine.

As per the exception, record 290 already existed in the collection, so did 291, 292, 293 and so on, up to record auto-numbered at 304.

Accordingly, the expected behaviour is that LiteDB would insert the document with the Id field value auto-generated at 305, the next incremented value.

For want of a better term, I suspected LiteDB had somehow “lost count”. I tried changing the code to explicitly set the Id field at 305, the value I was expecting auto-generated for the document the code was trying to insert.

This worked.

I then removed the Id field and tried another insert, relying on LiteDB to auto increment the Id field, which it started to do again - as I would have normally expected.

As I said, I’m not sure what led to this condition, but do suspect it to be a bug in LiteDB which is why I’m reporting this issue.

[mbdavid]

Hi @marcbarry, I have plans to release a new v4.1.5 with some fixes, but only after release v5 (I have lots of code/documentation to do).

[marcbarry]

Same for me @mbdavid - I cannot share the database, but I also did not keep a copy of the faulted version. Version 5 sounds like a good approach compared to version 4, however I’m sure there are trade offs which I don’t appreciate.

What do you propose as a fix @mbdavid? The highest version I can see on nuget is 4.1.4.

Also, thank you so much for this fantastic project!