Minimongo cache staleness after publication argument change

Question

This question addresses the observable window in which minimongo retains documents from a previous Meteor publication when a subscription is restarted with modified arguments. The goal is to characterize the conditions under which this staleness persists and whether it scales with network latency or server-side reactive timing. Key uncertainty involves the precise threshold at which the client's data source transitions from cached documents to server-removed messages, and how different Meteor release lines handle cleanup during argument changes.

Specific questions:

How does the stale-cache window duration scale with round-trip latency in Meteor release lines?
What triggers minimongo to purge cached documents when a publication's argument set changes mid-subscription?
Does supplying a version token in publication arguments guarantee immediate cache invalidation, or does it depend on the next server observeChanges cycle?

Tasadduq Burney · Answer

The Cause of Cache Staleness
Minimongo does not automatically purge documents when a subscription's arguments change. Because Minimongo is a passive store populated by DDP (Distributed Data Protocol) messages, it retains all documents until the server explicitly sends a removed message for each one. When you call Meteor.subscribe with new arguments, the client requests a new data set, but the documents from the previous subscription remain in the local cache until the server processes the unsubscribe request and emits the corresponding removals.

Scaling and Latency
The duration of the stale-cache window scales linearly with round-trip time (RTT) and server-side processing latency. The window is defined by the time elapsed between the client sending the new subscription request and the server delivering the removed messages for the old set. It is not a fixed timeout; higher network latency or expensive server-side observer teardowns will directly lengthen the period where stale data is visible in the UI.

Invalidation Triggers
Minimongo purges cached documents only when the following conditions are met:

The server-side observer for the old subscription is torn down.
  The server identifies documents that were part of the old result set but are not part of the new one.
  The server sends DDP removed messages for those specific document IDs.
  The document is not being tracked by any other active subscription (ownership tracking).

The Role of Version Tokens
Supplying a version token in publication arguments does not guarantee immediate cache invalidation. A version token merely changes the criteria the server uses to select documents. The actual removal of old documents still depends on the server's observeChanges cycle emitting removed messages. If the token causes the new publication to return a disjoint set, the cache will eventually clear, but only after the server processes the transition.

Recommended Resolution Steps

Gate UI Rendering: Do not render data-dependent components until the subscription handle is ready. Use the handle.ready() promise or the useSubscription hook to ensure the UI waits for the server's ready message.
  Explicit Handle Management: If an immediate empty state is required, manually stop the previous subscription handle before initiating the new one, though this may still leave a gap based on RTT.
  Verify via DDP Logging: Use browser network tools to inspect WebSocket frames. Confirm the sequence of sub → removed → ready to measure the exact staleness window.

Diagnostic Detail Required: Are the documents being retained coming from a single subscription, or are they shared across multiple overlapping publications? If documents are shared, they will never be purged until the final owning subscription is stopped.

Minimongo cache staleness after publication argument change

1 answer

The Cause of Cache Staleness

Scaling and Latency

Invalidation Triggers

The Role of Version Tokens

Recommended Resolution Steps

Your perspective belongs here.

0 question comments