Subscription onReady callbacks don't fire on a re-subscription with the same arguments inside Deps.autorun

[athiwatc]

_2 Upvotes_ I don't know if this is the intended behavior but lets assume that the server publish is setup.

Then we do

Deps.autorun ->
  Session.set('ready', false)
  Meteor.subscribe 'call-this', Session.get('something'), ->
    Session.set('ready', true)

Session.set('something', 2)
#wait for the subscibe to complete and the page shows
Session.set('something', 2)
#Now the loading page gets stuck. Note that the loading page uses {{#if}} against the 'ready' session.

I don't really have time to get an example working right now but I will try to if I get time.

My current hack/fix right now is adding a non-sense field to trick meteor on tearing and setting up the subscription and calling the on finish again.

Deps.autorun ->
  Session.set('ready', false)
  Meteor.subscribe 'call-this', Session.get('something'), Math.random(), ->
    Session.set('ready', true)

Session.set('something', 2)
#wait for the subscibe to complete and the page shows
Session.set('something', 2)
#Now the loading page gets stuck. Note that the loading page uses {{#if}} against the 'ready' session.

[mizzao]

I just ran into this. I think it's a bug. Meteor.subscribe should fire the onReady callback immediately if the re-subscribe inside Deps.autorun has the same arguments and the server isn't actually getting hit again. It currently only fires on the initial subscription, so on a router-triggered re-render my page gets stuck on loading spinners even though the data is ready.

@glasser: this bug is simple enough to understand, but do you want me to create a demo repo? I was just about to report it.

[mizzao]

Anyone, can we re-open this issue please? I will happily create a repro for it.

[estark37]

Reopening - a repro would be appreciated, @mizzao.

[mizzao]

The title should be changed to

Subscription onReady callbacks don't fire on a re-subscription with the same arguments inside Deps.autorun

I'll create a repro pronto.

[mizzao]

Hi @estark37, reproduction is here: https://github.com/mizzao/publish-autorun-onready.

When page loads, onReady is called for the initial subscription. When the subscription happens again with the same arguments, it is not actually sent to the server (as documented in http://docs.meteor.com/#meteor_subscribe) but the onReady callback is not called.

When the latter happens, onReady should be called immediately after the re-subscribe.

[glasser]

Yeah, that sounds reasonable. This falls into the case that we mention in a comment in livedata_connection.js:

        // If the sub is not already ready, replace any ready callback with the
        // one provided now. (It's not really clear what users would expect for
        // an onReady callback inside an autorun; the semantics we provide is
        // that at the time the sub first becomes ready, we call the last
        // onReady callback provided, if any.)

Perhaps it is now clear what users would expect!

I think the change is just to replace

        if (!existing.ready)
          existing.readyCallback = callbacks.onReady;

with

        if (existing.ready) {
          callbacks.onReady();
        } else {
          existing.readyCallback = callbacks.onReady;
        }

We would review a PR that made this change, updated the nearby comments appropriate, and added a test.

[mitar]

Just linking one for me related ticket: #1461, so I think we should have better ways to get callbacks when subscription stop, and how they are restarted.

Because it is not clear how this should behave. In some other situations you do not want onReady to be triggered if subscription didn't really close and come back. Maybe we need onReady, onRerun, onClose. onRerun would be called only if nothing changed, but it was rerun, onReady would be called for each new subscription.

[mitar]

So onReady, onRerun, onClose, onError.

[mitar]

Is this related to #2440? I think it maybe should be addressed together?

[mitar]

I looked in our code how we are doing it and found that we do this differently and this is why I have not encountered this issue:

var groupHandle = null;
var groupSubscribing = new Variable(false);

Deps.autorun(function() {
  if (Session.get('currentGroupId')) {
    groupSubscribing.set(true);
    groupHandle = Meteor.subscribe('groups-by-ids', Session.get('currentGroupId'));
  } else {
    groupSubscribing.set(false);
    groupHandle = null;
  }
});

Deps.autorun(function() {
  if (groupSubscribing() && groupHandle && groupHandle.ready()) {
    groupSubscribing.set(false);
  }
});

Template.group.loading = function() {
  groupSubscribing(); // To register dependency
  return !(groupHandle && groupHandle.ready());
};

Template.group.notFound = function() {
  groupSubscribing(); // To register dependency
  return (groupHandle && groupHandle.ready() && !Group.documents.findOne(Session.get('currentGroupId'), {
    fields: {
      _id: 1
    }
  });
};

Template.group.group = function() {
  return Group.documents.findOne(Session.get('currentGroupId'));
};

I think this is quite ugly and probably Meteor should provide some nicer way to do it.