Stopping cursor on server removes all its docs from client, doesn't it?

I’ve read the API doc and the guide, but they’re a little nebulous on this point. Just looking for a confirmation of my working assumption: If I stop a cursor on the server, that removes all its docs from the client (assuming any doc therein is not subscribed elsewhere) — right?

The situation is that I have a series of cursors supplying a view client-side. They, in turn, create other cursors that actually do that fire this.added, changed and removed for syncing docs to the client. Tracing, I can see changing the result set of the top-level cursors behaves correctly, and the sub-cursors are started and stopped correctly. Starting a cursor correctly adds its docs to the client. However stopping it does not remove them.

Thanks,
George

It’s been my experience that only relying on publications to control what’s visible on the front-end is bad practice - ie your helpers (if using Blaze) or other front-end queries need to specify what should be visible based on the current state.

So, yeah, stopping a subscription is good practice when it’s no longer needed but, even if you could determine that that would remove the documents from minimongo I wouldn’t rely on it. Your app might grow in such a way that in future the document is on the client for some other publication.

@Peter. Thanks. We’re doing all that. There’s plenty of logic on the front-end to make sure something doesn’t show if it’s no longer relevant.

My concern is twofold: (1) If stopping the cursor doesn’t discard the records, I’ve got a memory leak. (2) Worse, I’ve got a security problem if logging out isn’t clearing localstorage.

I take it from your reply that my operating assumption is correct. Surely, I’ve got a bug somewhere :slight_smile:

Sorry, I hadn’t considered your other concerns. I falsely assumed you were running queries in your publication but not in your view layer.

Not sure what the standard / proper behaviour is here with regard to minimongo clearing documents. Hopefully someone else with better knowledge can reply.