MongoDB shared transaction API exposes users to data loss

[mauroservienti]

MongoDB API exposes users to data loss due to the way the shared transaction API is designed. Take for example the following snippet:

public Task Handle(MyMessage message, IMessageHandlerContext context)
{
    var session = context.SynchronizedStorageSession.GetClientSession();
    var collection = session.Client.GetDatabase("mydatabase").GetCollection<MyBusinessObject>("mycollection");
    return collection.InsertOneAsync(session, new MyBusinessObject());
}

The last line is really easy to get wrong:

return collection.InsertOneAsync(session, new MyBusinessObject());

The InsertOneAsync method has many overloads one of which is very similar to the above one but doesn't take a session parameter as the first argument. If a customer writes the aforementioned snippet like follows:

public Task Handle(MyMessage message, IMessageHandlerContext context)
{
    var session = context.SynchronizedStorageSession.GetClientSession();
    var collection = session.Client.GetDatabase("mydatabase").GetCollection<MyBusinessObject>("mycollection");
    return collection.InsertOneAsync(new MyBusinessObject());
}

it compiles fine and it might also work, however the MyBusinessObject save attempt is not included in the shared transaction created by the endpoint.

It would be nice to add to the MongoDB package an analyzer to detect and warn users in case such a mistake is done.

[danielmarbach]

At first glance, it seems easy: just flag InsertOne/InsertOneAsync calls without a session parameter. But in reality, this approach would miss important cases and generate numerous false positives.

Whether an operation must be enlisted depends on whether a transactional context is actually active. In some handlers (outbox-only, immediate dispatch) writes outside a session can be intentional, so a blanket warning becomes noise.

We can detect something like:

var s = context.SynchronizedStorageSession.GetClientSession();
await collection.InsertOneAsync(new MyDoc()); // missing 's' → warn

But as soon as code goes through helpers, repositories, or DI, the analyzer can’t see the actual call.

Repositories and helper methods make it impossible for a local rule to catch missing sessions:

public Task Add(MyDoc doc) => coll.InsertOneAsync(doc); // no session here

At the call site (repo.Add(...)), everything looks fine.

MongoDB exposes many overloads (InsertOne, ReplaceOne, BulkWrite, etc.). Picking the “wrong” one is easy. On top of that, sometimes writes are intentionally out of band (audit logs, metrics), so warnings aren’t always correct.

ITransactionalSession is often used outside of handlers with DI scopes. A handler-scoped analyzer won’t catch those, and interprocedural dataflow across async boundaries is far from trivial.

[danielmarbach]

@mauroservienti I'd propose to close this one