Sorry, I haven’t had my coffee yet. If I am reading this correctly, either someOp() or someOtherOp() may execute first, no? And if you introduce an external database, why do you expect Mongo to handle that rollback? Say someOtherOp() increments a Redis value by 1. If that part executed first since both are asynchronous here, what would a Mongo session have to do with it?

What exactly would invalidating that session object do here? And what would the session object do after it was invalidated?

It sounds like the old session object is reused and becomes live again or something.

Thanks for this explanation. So if I understand correctly, `someOp` has thrown an error but this doesn't affect `someOtherOp`? So `someOtherOp` will end up being called twice?

Correct, the easy workaround is not to use that transaction API and write your own disposer instead of using withTransaction.

I think this is the expected behaviour of the transaction but the problem comes from the fact you wrap all DB operation inside a Promise.all.

Because you wrap the DB operations inside a Promise.all, it means it will run them all BUT it will not revert them if one fails (it's not atomic, it just says that one has failed and you need to catch it), it will reject them but not revert them. (the CUD operation will already have changed the data) The problem I believe is the transaction is considering the Promise.all and not what's inside of it so it will run it again despite the fact that some have already succeeded earlier

I think you just have to resolve each of them outside a Promise.all. In your case because Promise.all has been rejected it will redo the transaction, therefor it will redo the one that have already worked in the first call.

I'm no expert but this is how I understand it.

Not op, I think what he means is the session, even when already failed once, can still be used (without error) in the next operation without being invalidated.

Without promise.all, I think it can be replicated like this:

    try{
      await someOp(session);
    catch { }
    await someOtherOp(session);

He expected what the session to be invalidated during someOtherOp.

That is correct and what I meant. Thanks, and there doesn't have to be a `try/catch` because it is possible to "fork" control with promises.

They implemented a "disposer" incorrectly (I added this to several other libraries and made a Q&A about it here https://stackoverflow.com/questions/28915677/what-is-the-pro... )