Minimongo cache persists stale documents after server publication update

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?