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.
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.
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 });
},
}
});