Hit another nasty bug with collection hooks today in production. Wanted to leave it here in case I jump in and try to fix these.
My use case is inserting a document into an ordered list of documents that are paginated by pages of ten documents. They use an order field for the ordering.
If you have a simple collection hook like:
Documents.before.insert(function (userId, doc) {
// Increment the order of all existing documents after this document
var order = doc.order;
Documents.update({order: {$gte: order}}, {$inc: { order: 1}}, {multi: true});
});
And you do an insert:
let someDocument = {text: "someText", order: 3};
Documents.insert(someDocument);
And you have a publication (I've intentionally broken out the functions for debugging and am logging each one):
For some reason calling an update on the same collection in its before.insert hook, in some cases, will actually totally prevent the original insert from firing an added call to the publication. It happens in both an old-school client insert and a Meteor Method insert. And it will happen no matter if I use the before.insert or after.insert hook. It seems like Meteor is "grouping" up the publication calls and having this update to the same collection in the hook causes issues.
For some weird reason it usually only happens when users are past the first page of pagination in my app. Everything works fine on the first page. As soon as I comment out that hook, the added call to the publication fires fine. With the hook, I only get the changed calls to the documents with a higher order number that get incremented.
So somehow that update is affecting the insert's added call to the publication. If I page back or refresh, the data is actually inserted, it just doesn't fire an added call. So my client looks like it failed. My work-around is to do the incrementing in a Meteor Method in the callback of the insert.
I will try to work on these (or further investigate using Node's events versus this package).
Hit another nasty bug with collection hooks today in production. Wanted to leave it here in case I jump in and try to fix these.
My use case is inserting a document into an ordered list of documents that are paginated by pages of ten documents. They use an
order
field for the ordering.If you have a simple collection hook like:
And you do an insert:
And you have a publication (I've intentionally broken out the functions for debugging and am logging each one):
For some reason calling an
update
on the same collection in itsbefore.insert
hook, in some cases, will actually totally prevent the originalinsert
from firing anadded
call to the publication. It happens in both an old-school clientinsert
and a Meteor Methodinsert
. And it will happen no matter if I use thebefore.insert
orafter.insert
hook. It seems like Meteor is "grouping" up the publication calls and having thisupdate
to the same collection in the hook causes issues.For some weird reason it usually only happens when users are past the first page of pagination in my app. Everything works fine on the first page. As soon as I comment out that hook, the
added
call to the publication fires fine. With the hook, I only get thechanged
calls to the documents with a higher order number that get incremented.So somehow that
update
is affecting theinsert
'sadded
call to the publication. If I page back or refresh, the data is actually inserted, it just doesn't fire anadded
call. So my client looks like it failed. My work-around is to do the incrementing in a Meteor Method in the callback of theinsert
.I will try to work on these (or further investigate using Node's events versus this package).