5 ms·
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
by Namari 6y ago
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.
- gabrieledarrigo 6y agoThis is right. Are you sure nglor that you know how to write code?
- couchand 6y agoPlease be civil.
- inglor 6y agoI have found people to attack me when I make a technical criticism of technologies they like. Am I expected to justify being able to code in HN? I could go on about being a maintainer of the two most promise libraries in npm (bluebird and Q), being node core, organizing promises sessions for APIs in Node core and having over 1000 answers about promises in SO. I generally find that sort of "non-technical chat" boring compared to the technical stuff and appeal to authority kind of lame. The only other person attacked in this issue is aphyr, so I believe I am in very good company in this particular instance.
- fendy3002 6y agoNot 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.
- inglor 6y agoThat 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-promise-disposer-pattern https://stackoverflow.com/questions/28915677/what-is-the-pro... )