Why does withTracker() unsubscribe right after subscribing?

waldgeist · May 27, 2021, 10:26am

I used Meteor Dev Tools to analyze DDP communications between my React frontend and my backend. I noticed that every time a withTracker() computation re-runs and re-subscribes to an existing subscription, the subscription of the previous run will be unsubscribed (by sending UNSUB right after SUB).

If I call Meteor.subscribe() directly using the browser console, however, this does not happen.

So I am wondering why withTracker() unsubs the subscription. Is this necessary to avoid that multiple subs from the same component stay active?

I am asking this because I am developing my own DDP client and want to mimick the correct behavior. The DDP docs are somewhat limited.

Also, I am wondering if this is actually a behavior of withTracker() or some magic that Tracker does in the background, in combination with subscribe().

waldgeist · May 27, 2021, 12:10pm

Ok, after investigating the code of subscribe()

github.com

meteor/meteor/blob/master/packages/ddp-client/common/livedata_connection.js#L347


 * @locus Client
 * @param {String} name Name of the subscription.  Matches the name of the
 * server's `publish()` call.
 * @param {EJSONable} [arg1,arg2...] Optional arguments passed to publisher
 * function on server.
 * @param {Function|Object} [callbacks] Optional. May include `onStop`
 * and `onReady` callbacks. If there is an error, it is passed as an
 * argument to `onStop`. If a function is passed instead of an object, it
 * is interpreted as an `onReady` callback.
 */
subscribe(name /* .. [arguments] .. (callback|callbacks) */) {
  const self = this;


  const params = slice.call(arguments, 1);
  let callbacks = Object.create(null);
  if (params.length) {
    const lastParam = params[params.length - 1];
    if (typeof lastParam === 'function') {
      callbacks.onReady = params.pop();
    } else if (lastParam && [
      lastParam.onReady,

once more, I think I understand what happens:

If a (Tracker) computation becomes invalidated, all existing subscriptions are being “deactivated” (inactive = true)
If there is a subscribe() inside the computation that has exactly the same name and parameters, the subscription is being reactivated (inactive = false). This prevents that it is being re-run or unsubbed.
If there is a subscribe() with the same name, but different parameters, a new subscription is created. The old one (with the same name) will be unsubbed onAfterFlush(), i.e. after the new one has been subbed.
If there is no subscribe() with the same name at all, the existing sub will just be unsubbed without a recplacement.

So, to answer my own question: This is default behavior of Tracker and ensures that a) there is exactly one subscription with the same name per computation and b) there can be multiple subscriptions with the same name in different computations.

waldgeist · May 27, 2021, 12:23pm

My remaining question here is: What does the server expect if the WebSocket connection breaks up at some point of time, e.g. because of an unstable mobile connection?

Will it purge all subscriptions automatically, or does it still expect that the same client would unsub them after re-subbing to them on re-connect?

minhna · May 27, 2021, 1:43pm

I’m not sure but this issue could be related: Double subscriptions when using useTracker in lazy components · Issue #324 · meteor/react-packages · GitHub

captainn · May 27, 2021, 2:51pm

All of this looks right. The most recent version of withTracker (and useTracker) patched a problem around exactly that “magic” behavior.

There’s even a set of really old tests to validate all that:

github.com

meteor/react-packages/blob/cd80a890322d7ebf537464bc178577fe83927ccd/packages/react-meteor-data/withTracker.tests.js#L262




function waitForTracker(func, callback) {
  Tracker.autorun(function (c) {
    if (func()) {
      c.stop();
      callback();
    }
  });
};


testAsyncMulti('withTracker - resubscribe', [
  function (test, expect) {
    var self = this;
    self.div = document.createElement("DIV");
    self.collection = new Mongo.Collection("withTracker-mixin-coll");
    self.num = new ReactiveVar(1);
    self.someOtherVar = new ReactiveVar('foo');
    self.Foo = withTracker(() => {
      self.handle =
        Meteor.subscribe("withTracker-mixin-sub",
                          self.num.get());

captainn · May 27, 2021, 2:54pm

I still have to look in to this particular issue - but I don’t know if it’s been tested since the most recent release.

waldgeist · May 28, 2021, 7:09am

Thanks for your response and confirming my observations!

captainn · May 28, 2021, 2:21pm

I don’t know what happens on the server side, but there is a reconnect event (distinct from connect) you can listen for on the client side, to display a “attempting reconnect in {XXX} seconds”, so there’s definitely some kind of consideration for this.

waldgeist · May 28, 2021, 4:43pm

Thanks, but I am actually using a DDP library in Unity, so this would not work. Currently, I am re-examining the whole DDP communication handshakes, because I am facing a weird issue with dropped RESULT messages once I login after a connection breakup (unstable mobile connections):

github.com/meteor/meteor

Login method returns UPDATE but no RESULT

opened 12:35PM - 28 May 21 UTC

derwaldgeist

Project:DDP Project:Accounts (in user apps) good first issue

Our Unity app connects to a Meteor server via DDP, so we had to roll our own DDP… protocol implementation, based on an [old library by Greencoder](https://github.com/green-coder/unity3d-ddp-client). It works fine, but we are facing an odd behavior of the `login` method (with a resume token) if we re-connect the app after the user put it in the background and back (the WebSocket connection has to be re-established as well). In this case, quite often we only receive an `UPDATED` message, but *not* the `RESULT` message confirming the login. This happens more often on Android than on iOS. We're wondering what the reason for this is and if there is a workaround? When experimenting with the setup, we noticed that it works more reliably if we logout explicitly immediately before logging in again. However, it's not 100% reliable, so it's not really a solution. BTW: We also noticed that if we do call logout immediately before the login, the Meteor server won't always remove the login token from the database as it normally would. If we try the same in the regular Meteor frontend, the token will be removed reliably. The web frontend also never showed the problem that RESULT was not sent on login (we debugged this using the Meteor Dev Tools). We only see this odd behavior in our Unity app. Meteor version: 1.10.2

It’s a phenomenon that mainly appears on Android devices. The login method works, but sometimes it won’t send RESULT back, only UPDATED. I have no clue so far what causes this behavior. It doesn’t happen in the regular Meteor web frontend. I can see no reason why the server should only send one of these acknowledgements. The DDP docs are pretty vage.