Minimongo limited query initially returns all documents


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)

has anyone had this issue?

Quick question, do you have insecure and autopublish enabled still?


it shouldn’t matter if I have 500 documents exposed through autopublish, only the limited number is requested

Can you publish a reproduction of the issue to github?

the code is quite complex, involving project-specific Iron routes and subscriptions

perhaps more details about my case would help:

  1. 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

  2. the first template stops all the subscriptions when it’s destroyed

  3. 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

Kind of a guess game without a code example.

Does putting the subscription in a waitOn iron router option fix it?

I’m probably wrong, but could your issue be the same as this issue? More specifically this comment?

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

thanks for your interest

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.

1 Like

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.”

1 Like

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

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.

Hope that helps

1 Like

only one template has an {{#each}} with a unique helper and a unique cursor within
the other template uses the same collection for other purposes

as for data contexts, the 2 templates are independent of each other (i.e. they’re not sub templates of each other)

even if there were 2 {{#each}}'s on 2 different templates with 2 different cursors, this would imply a cross-talk in the Platform

no matter how you turn it, this is unexpected behavior which the application writer cannot anticipate

@alanning alright, I hope I would be able to repro it


I had this EXACT problem. Been bugging me all night.

I started a new Meteor project, got started, and started data security.

return Posts.find({ type:“messages” }, {sort: { createdAt: -1 }, limit:10 });

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.