Question
Minimongo cache persists stale documents after server publication update
Rey Dey
0 reputation · 31 May 2020, 04:34 UTC
47.7K views1
Loading…
0 reputation · 31 May 2020, 04:34 UTC
Meteor's minimongo cache stores documents locally and serves them to reactive computations until the server publishes updates. When a publication's logic delays change propagation, the client may render stale data without automatic indication. The onReady callback in Meteor.subscribe fires after the initial document batch is received, but it does not confirm that subsequent server updates have been applied or that the cache is current.
Conversely, onStop removes the subscription cursor but does not purge minimongo entries, allowing old documents to persist until a new subscription activates. In Meteor 2.x and later, the onStop callback is reliably supported; however, earlier releases may not invoke it during unsubscription, affecting cache clearance expectations.
Under what conditions does the minimongo cache consider a document stale after a publication update?Does onStop reliably purge cached documents, or do they persist until resubscription?How can a reactive computation detect that cached data is out of sync with the server publication?35275 reputation · 31 May 2020, 14:52 UTC
meteorchanged, added or removed message for that _id after the underlying data changes. This happens if the publication’s query depends on a non‑reactive source, if the server mutates the collection without calling the appropriate publish callbacks, or if the client‑side _id (or collection name) differs from the server’s version.onStop callback is reliably invoked when a subscription is stopped, but it only removes the subscription cursor; it does **not** automatically delete the corresponding Minimongo documents. Those documents remain in the client cache until a new subscription with the same name brings fresh data, or until you manually clear the collection._version field) with the value stored locally, or by checking subscription.ready() together with a reactive data source that re‑runs when the subscription status changes. If the computation re‑runs after ready() becomes true and the data has not changed, you know the cache is stale.The most common cause is a publication that does not re‑run when its underlying data changes, so the server never pushes the update to the client. Another frequent cause is a mismatch in the document identifier (e.g., a transform that alters _id) which prevents Minimongo from matching the incoming update to the existing cache entry.
added, changed or removed message for a matching _id and collection name.onStop callback fires reliably in Meteor 2.x+ but does not purge Minimongo entries; it only clears the subscription handle.subscription.ready() or on a version field sent by the publish function will re‑run when the subscription status changes or when the version changes, allowing detection of stale cache.console.log inside the publish function or use a DDP debug tool to confirm changed/added/removed are emitted after the data change.Tracker.autorun or are reactive data sources (e.g., Meteor.user(), Session)._id; if you need a transform, keep the original _id field unchanged.MyCollection.remove({})) inside the onStop callback, or re‑subscribe with a different subscription name.this.added('myColl', id, {..., _version: Date.now()})) and compare it locally; or wrap the UI in Tracker.autorun(() => { if (sub.ready()) { /* use data */ } }) and observe whether the data updates after ready() becomes true.Are you running Meteor 2.x or an earlier release? The reliability of onStop differs between versions and influences whether you need to manually clear Minimongo on unsubscription.
Use comments to ask for clarification. Post a solution as an answer.
6,590 reputation · 31 May 2020, 06:08 UTC
Minimongo is per collection name, not per subscription handle. Stopping one subscription with onStop removes the handle and its ready() dependency but does not purge the documents from the client collection. If another active subscription, or a local query, references the same collection, those documents remain readable and reactive.
For Meteor 2.x and later, onStop is reliably invoked on unsubscription, yet the cache is intentionally left intact. Practical verification is to stop a subscription and inspect the collection contents; they persist until a new publication sends changed/removed messages or the collection is cleared manually.