[BUG] Race condition in BsonMapper

[einarmo]

Version LiteDB 5.0.21 .NET 8.0.401 Linux (Fedora 38)

Describe the bug Specifically, what I see is an occasional stacktrace:

System.NotSupportedException : Member Id not found on BsonMapper for type MyNamespace.MyType
 Stack Trace:
at LiteDB.LinqExpressionVisitor.ResolveMember(MemberInfo member)
at LiteDB.LinqExpressionVisitor.VisitMember(MemberExpression node)
at LiteDB.LinqExpressionVisitor.ResolvePattern(String pattern, Expression obj, IList`1 args)
at LiteDB.LinqExpressionVisitor.VisitMethodCall(MethodCallExpression node)
at System.Linq.Expressions.ExpressionVisitor.VisitLambda[T](Expression`1 node)
at LiteDB.LinqExpressionVisitor.VisitLambda[T](Expression`1 node)
at LiteDB.LinqExpressionVisitor.Resolve(Boolean predicate)
at LiteDB.BsonMapper.GetExpression[T,K](Expression`1 predicate)
at LiteDB.LiteCollection`1.DeleteMany(Expression`1 predicate)

when running an expression like

collection.DeleteMany(item => idsToDelete.Contains(item.Id))

Code to Reproduce I cannot reproduce this consistently, it only happens once in a while, likely while I am running multiple concurrent transactions not against the same collection, but using the same types.

I believe this is a race condition caused by #2493, here's the possible race I see that this PR introduced:

• Thread A enters GetEntityMapper here, and does not find the mapper.
• Thread A calls BuildAddEntityMapper, and goes past this line, adding an entity mapper to the _entities dictionary.
• Thread A is preempted by thread B, which enters GetEntityMapper.
• Thread B finds a mapper and returns, but this mapper won't work, as it has not yet been populated with fields, resulting in the stacktrace above.

This code has existed for a long time, and this issue only started after updating to the latest version, which contains this fix. There may be a different cause, though my trace above seems plausible.

[JKamsker]

Oh i see it now. Thats pretty bad, i am sorry for that. Would you mind pr'ing a fix?

[einarmo]

I made a PR with a simple fix, though I'm not sure it is the best solution, since it will come with a performance cost that I think the original author of this code wanted to avoid.

[JKamsker]

Performance < Stability

[JKamsker]

Hey @einarmo can you have a look at my pr and if it solves your issue? My solution doesnt require locking all the time and should still be safe from race conditions