Closed rjsmith closed 9 years ago
Wow! Thanks for identifying this. A nasty little bug with closures and changing of the surrounding data context. I did reproduce it (thanks to your thorough analysis above) and have just released a new version of the package (0.6.16) with the fix.
Hi, I think I have found a bug relating to processing updates which have multiple modifiers (my example has a $addToSet and a $set in the same collection.update() statement that is wrapped in a tx transaction)
I added some console logging to the
makeUpdate
function to see what is going on .. please see trace below:You can see that
makeUpdate
is called twice (correctly) from thecommit
function. But, each invocation has the sameupdateData
andinverse
arguments (both from the 2nd update item).This is the resulting tx.Transaction document:
You can see that the
$addToSet
update has disappeared, and replaced with a duplicate copy of the$set
update.My guess is that there is a problem in binding / capturing the arguments when the
makeUpdate
calls are added to the_executionStack
list in the Transact.prototype.update function at line https://github.com/JackAdams/meteor-transactions/blob/master/lib/transactions_common.js#L571It's weird, because the actual committed updates work OK (they come from the
updates
array, which is OK?), but the transaction data recorded in tx.Transactions uses theupdateData and
inversearguments (which are wrong for the first update), which is why the subsequent
tx.undo()` in my test only reverses the second original update item , and not the first.