New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meteor.subscribe onReady callback called before sub marked ready #4614

alexcorre opened this Issue Jun 23, 2015 · 3 comments


None yet
3 participants

alexcorre commented Jun 23, 2015

Hi Meteor Team!

I had a question about these lines of code:

When we receive a ready message for a subscription we call the readyCallback before actually marking the subscription as ready. Is there a reason for this? I want to achieve the following but cannot:

Lets say we have a subscription called someSub that publishes some interesting data. This interesting data is used by getSomeData(). I want to make sure that developers on my team dont call getSomeData until the someSub subscription is ready, since it could lead to unpredictable and particularly buggy state.

Now, in the example below, I call getSomeData within the onReady callback function, and it still throws an error.

MySubs.something = Meteor.subscribe('someSub', function() {
    // do some stuff...

   var data = getSomeData();

   // do some more stuff...

inside getSomeData

function getSomeData() {
   if (!MySubs.something.ready()) {
     // THIS THROWS when i call getSomeData from the ready callback.
    throw new Error()

  // do some important stuff with the data published by someSub

This may just be an edge case, but to me. it seems that ready() should return true from inside the readyCallback. What do you think?


This comment has been minimized.

ccorcos commented Jun 24, 2015

Something just to watch out for: MySubs.something.ready() is reactive. So maybe theres an autorun you're not expecting.


This comment has been minimized.

ccorcos commented Jun 24, 2015

Not sure why this functionality happens -- maybe due to the flush cycle. In the meantime, Meteor.defer would probably be a suitable workaround.

@glasser glasser added the Project:DDP label Jun 30, 2015

@glasser glasser closed this in 447d236 Jun 30, 2015


This comment has been minimized.


glasser commented Jun 30, 2015

Good point! I don't think anyone ever thought carefully about this, and it definitely makes sense the way you suggest.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment