For an unknown reason, a client query specifying a limit (e.g. collection.find({}, { limit: 3}); ) initially returns all the docs in the collection, and only in a reactive re-iteration limits the query.
In my specific case, I have a template helper which returns a limited query and is used in an #each block
However, when it’s invoked for the first time, it returns all of the collection (indicated by a console.log(query.count()) and all of the documents being visually rendered to the page for a brief moment)
the code is quite complex, involving project-specific Iron routes and subscriptions
perhaps more details about my case would help:
this happens when I navigate from one template, which has subscriptions to many documents in a collection,
to another template, which only queries 3 documents in the same collection, with its own subscription
the first template stops all the subscriptions when it’s destroyed
the result is all documents “leak” into the 2nd template, and show up in a limited query
the leakage is one issue, but regardless of it the limited query should still pull out only 3 documents
I gave the background story, but it’s sort of beside the point
no matter how many subscriptions I have, limiting a query should always return just the limited # specified
the issue here is with Minimongo allowing the query to exceed its limit momentarily
In any case, the answer to your question is I can’t put the subscription in a waitOn - it’s a changing subscription which is required within the template
query.count() works fine - when the query stabilizes and actually limits the documents, it returns the limited number
beside the debugging output, the actual application of the query shows me that the limit is not applied (i.e. I see DOM elements rendered for all documents instead of a limited number)
I’d say that you’ve basically answered your own question. The subscription is leaking because of timing issues associated with how the subscriptions are attached to the templates. Try re-scoping your subscriptions. Bring them into the application global context, or some scope common to both/all the relevant templates. Use a reactive session variable and tracker to reactively re-subscribe to the collection, and trigger the route change or re-render after the subscription is finished. Adding more logic to your code isn’t going to help. You need to be removing logic, re-scoping, and refactoring.
so far everybody’s been overlooking the fundamental issue here
suppose I have a leakage - this only affects the total number of documents in the local collection
however, the query must always return at most the limited number, regardless of how many documents there are in total
if a limited query returns more documents than expected, the minimongo logic is broken
You said it only happens when you change pages? Without your actual code I am going to guess the following. The template you are navigating away from is caching N documents and displaying them. They are in an {{each}} loop with the same structure as the page with your limited query. When you go to the new page, the page isn’t waiting for your query to be executed so it is using the same local collection of N cached documents and iterating through that with what I’m assuming to be a similar {{each}} loop. Your code eventually limits the query and returns only what you are asking it to which would cause it to “flash” for a second before it has completed it’s computation. This does not sound like a problem with minimongo but rather your applications logic and how you’re handling the data-contexts of your templates. Again without the code itself it’s almost impossible to tell what’s wrong with it especially if it is “quite complex.”
If this is a bug in meteor or blaze, you’ll need a repro in order to log an
issue. See here for more details -
I’d recommend starting your repro with just the three scenarios that you
listed and adding as necessary to reproduce the issue.
Without a repro, a detailed log will be the second best bet to track this
down.
For your case, log whatever you can to make sure what you suspect is
happening is truly occurring. Try making your templates explicitly visually
different and outputting console logs for template lifecycle events. Log on
subscription ready and output contents of the collection at relevant times.
That should work from the server side of things, right? Wrong.
SOULTION: Meteor reset.
I had manually edited .packages and removed auto publish. For some reason, it didn’t get fully removed. So I nuked it with a Meteor Reset and bam, works.
So it looks like your client side is ignoring the publications information, and getting all data. That’s why the limit works client side but not server side.