$inc operator field not always incremented on client side collection

Hi,

I have a server-only method that runs this code (simplified version):

    let doc_id = await collection.insertAsync({ index: 0 });
    await collection.updateAsync(doc_id, { $inc: { index: 1 } });

After this code is executed, on the server side the value of ‘index’ is always correctly incremented to ‘1’ as expected, however on the client side (Minimongo), ‘index’ value remains ‘0’ in about 70% of the cases.

When replacing the code with its sync versions:

    let doc_id = collection.insert({ index: 0 });
    collection.update(doc_id, { $inc: { index: 1 } });

The problem is still there, but less frequently, in about 20% of the cases.

I am using Meteor version 2.15.
Did anyone else experience this behavior?

Update: problem comes from using publishComposite() in ‘meteor-publish-composite’ package, regular Meteor.publish() updates client docs as expected.

Can you post here how your publishComposite function looks like?
Also are you using the reywood:publish-composite or another variant?

Well, it turned out the problem was only there in combination with using transactions (jam:mongo-transactions). I also have other weird client-side behavior then:

however I haven’t been able yet to put it in a simple repo. So for the time being I have temporarily disabled transactions in my project.

I am using reywood:publish-composite.

Ah… and this is what I found in my publishComposite code, which may be of interest to you… especially the comments that explain the problem and how I made a workaround.

(In my previous response I wrongly connected the problem with the weird behavior I got with transactions, but looking at the ‘fix’ below, it has nothing to do with it I remember now… sorry for the confusion)

(<any>publishComposite)("colHistoryXXX.songPage", async /*= not defined in .d.ts file yet*/function (songPageDoc_id: string) {
    return {
        find: function () {
            //console.log("colHistoryStacks.find()");
            return colHistoryStacks.find({ songPageDoc_id: songPageDoc_id, creator_id: this.userId });  // (*2)
        },
        children: [
            {
                find: async function (historyStackDoc: tp.HistoryStackDoc) {
                    // To reduce server/client bandwidth and client memory, limit published collection doc to 5 (*1) next undo and redo events only
                    // (*1) We choose 5 so that when optimisticUI (*g68) is enabled client UI shows correct undo/redo event descriptions while server is still catching up. 
                    let historyEventDoc_ids = await getNextUnRedoHistoryEventDoc_idsAsync(historyStackDoc, 5);
                    return colHistoryEvents.find({ _id: { $in: historyEventDoc_ids } });
                }
            },
            {
                find: async function (historyStackDoc: tp.HistoryStackDoc) {
                    // To reduce server/client bandwidth and client memory, limit published collection docs to 5 (*1) next undo and redo actions only
                    let historyEventDoc_ids = await getNextUnRedoHistoryEventDoc_idsAsync(historyStackDoc, 5);
                    return colUnRedoActions.find({ historyEventDoc_id: { $in: historyEventDoc_ids } });
                }
            }
        ]
    }
});

// (*2) colHistoryStacks at client is not always updated correctly when consecutive sync or async doc updates happen at server, e.g.
// inside addEventToHistoryStackAsync()
//
//  let historyStackDoc = { creator_id: creator_id, songPageDoc_id: songPageDoc_id, curIndex: 0, test: 1 };
//  historyStackDoc._id = await colHistoryStacks.insertAsync(historyStackDoc);
//  await colHistoryStacks.updateAsync(historyStackDoc._id, { $inc: { index: 1 }, $set: { test: 2 } });
// 
// will not have 'index' incremented to '1' and 'test' set to '2' in client side colHistoryStacks in 80% of the cases.
// Changing to sync doc updates improves the buggy behavior but still shows the problem in 20% of the cases. 
//
// Additional but unnecessary code below seems to fix this unexpected behavior though... don't know why, and what else is still wrong with this package... 

(<any>publishComposite)("colHistoryStacks.songPage", async /*= not defined in .d.ts file yet*/function (songPageDoc_id: string) {
    return {
        find: function () {
            //console.log("colHistoryStacks.find()");
            return colHistoryStacks.find({ songPageDoc_id: songPageDoc_id, creator_id: this.userId });
        },
    }
});