Reported on slack: https://meteor-community.slack.com/archives/CN350MY1G/p1704695310758029

Some time back, we were tasked with addressing an issue occurring in a specific code scenario that seems to break isomorphism.

The next code behaves differently on the client and the server in Meteor 3.x, disrupting isomorphism. The operation should align on both client and server, the client's minimongo isn't populated with data by default, even though the server inserts data correctly into Mongo.

 const NamedCollection = new Meteor.Collection('namedCollection');
    
 await NamedCollection.insertAsync({ test: 1 });
    
// In the client it doesn't log the data inserted
// In the server it logs the data inserted
console.log("-> isItemCreated?", NamedCollection.find().fetch()?.[0]);

The problem lies in the code behaving differently in Meteor 2.x and 3.x. It populates in the former but not in the latter. See the next picture to clarify:

The problem not only happens in insertAsync but also in other operations such as updateAsync and removeAsync.

This problem mainly occurs in testing scenarios, not broadly, as minimongo is typically populated and utilized by functions following proper reads from publications or methods, not as a result of collection operations.

A use case where happens is for example on tests: https://github.com/Meteor-Community-Packages/mongo-collection-instances/pull/40/files#diff-bbd9a41e09b247b7b1128731dc48f53d701e08e4ad08bba374523b3f4f23d43c

Fix

Aligning the operations of Meteor 2.x and 3.x is achieved by introducing the resolverType option for collections (new Collection(name, options)). In Meteor 3.x, a distinction exists between stub and server promises. The former handles client simulation and minimongo population, while the latter solely manages success or error on the server call without populating the data in minimongo. The data is persisted on the server in both. The default is the server promise throughout Meteor 3.x codebase and tests, that is why changing to stub is not an easy option, above all being this an edge case.

The resolverType option offers stub and server values. Using stub maintains collection operation behavior to align with Meteor 2.x, addressing the isomorphic challenge.

 const NamedCollection = new Meteor.Collection('namedCollection', { resolverType: 'stub' });
    
 await NamedCollection.insertAsync({ test: 1 });
    
// In the client it logs the data inserted
// In the server it logs the data inserted
console.log("-> isItemCreated?", NamedCollection.find().fetch()?.[0]);

Check the test to see this new option in action:
https://github.com/meteor/meteor/blob/319-fix-client-op--remote-collections/packages/mongo/mongo_livedata_tests.js#L4279-L4304

Test

• Add a test for this regression