Is it by intention that subscription-ids aren't unique? Or ... should subscriptions be stopped before re-creating on a new connection?

core
1

When working with the extension meteor-publish-join I came to a very weird wiring of happenings which lead to that I had two subscriptions opened by the same user on different connections :confused:

A long story and it’s outcome:

The extension meteor-publish-join allows me to run a db-query periodically and report changes to the client. It does this by using the methods this.added(), this.changed() and this.onStop().

A subscription of this kind looks like this from the “user” perspective:

Meteor.publish('zones.count-by-status', function aggregateZones(key, selectors) {
  JoinServer.publish({
    context: this,
    name: `zones.count-by-status.${key}`,
    interval: 1000,
    isShared: true,
    doJoin() {
      return Zones.aggregate([
        { $match: selectors },
        { $group: { _id: '$status', count: { $sum: 1 } } },
      ]);
    },
  });

  this.ready();
});

I’ve now asked for a feature where the same subscription is established by multiple clients and the result is shared among them (https://github.com/nlhuykhang/meteor-publish-join/pull/4). In this fix the author assumed that the subscription-id is unique - also across connections.

A while ago I discovered that this extension runs into an endless-loop which is created as following:

I’ve added quite some debugging to nail it down. When opening the website where I subscribe to this subscription, I see the following data in my logs:

[2018-07-16 08:55:12.285][JoinServer] Initializing join zones.count-by-status.{"projectId":"itT628DxY6TPMC4wP","deleted":false} - f31b14d0-88d5-11e8-a255-730f22055160 for subscription 7iTJ4jah2gBXvNH6o on connection zLrmptXZKMrDPC9mv by user Sg2FfTrriRckabziy
[2018-07-16 08:55:12.286][JoinServer] Starting the publish worker
[2018-07-16 08:55:12.287][JoinServer] The connection zLrmptXZKMrDPC9mv on address 92.76.129.37 is using the user-agent Mozilla/5.0 (Linux; Android 8.1.0; Build/OPM1.171019.011) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Mobile Safari/537.36

This output is quite normal and also what I expected to happen. It shows that the extension runs and publishes the result of my long-running task periodically. Most important to you should be the ids of the connection, subscription and user - as well as the user-agent.

After a while this user (in this case it’s me) decides to switch to a different network because his network-speed went south or he went out of range. The logs will now show the following data:

[2018-07-16 08:55:30.476][JoinServer] Linking the existing join f31b14d0-88d5-11e8-a255-730f22055160 to the subscription 7iTJ4jah2gBXvNH6o on connection CjwwXBtyM9XjyXxZb by user Sg2FfTrriRckabziy
[2018-07-16 08:55:30.477][JoinServer] The connection CjwwXBtyM9XjyXxZb on address 109.41.64.21 is using the user-agent Mozilla/5.0 (Linux; Android 8.1.0; Build/OPM1.171019.011) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.87 Mobile Safari/537.36

This “linking with existing” happens if this subscription (identified by the join-subscription-key) is called a second time while another one is still publishing. To prevent a heavy load on the server, I share the results. Strangely enough, this new subscription here has the same id as the one still running, but a different connection-id.

And a blink of an eye later it shows:

[2018-07-16 08:55:44.275][JoinServer] Removing the subscription 7iTJ4jah2gBXvNH6o on connection zLrmptXZKMrDPC9mv by user Sg2FfTrriRckabziy from join f31b14d0-88d5-11e8-a255-730f22055160
[2018-07-16 08:55:44.275][JoinServer] Cleaning up empty join f31b14d0-88d5-11e8-a255-730f22055160
[2018-07-16 08:55:44.276][JoinServer] Stopping the publish worker
[2018-07-16 08:55:44.276][JoinServer] Publish worker is stopped

Ah, now the stop is fired for the subscription on the first connection …

Keep in mind that I have kept my website opened and the subscription is still (or again) running.

Now when closing the tab I get:

[2018-07-16 08:55:57.820][JoinServer] Removing the subscription 7iTJ4jah2gBXvNH6o on connection CjwwXBtyM9XjyXxZb by user Sg2FfTrriRckabziy from join f31b14d0-88d5-11e8-a255-730f22055160
[2018-07-16 08:55:57.820][JoinServer] Cleaning up empty join f31b14d0-88d5-11e8-a255-730f22055160
[2018-07-16 08:55:57.820][JoinServer] Stopping the publish worker
[2018-07-16 08:55:57.821][JoinServer] Couldn't stop the publish worker, try again

As you can see here, the this.onStop() method of the subscription, which was created before switching the network, got stopped after the subscription on the connection for the new network was ready.

Now my question (I hope you’re still sticking around with me :sweat_smile:):

As I said in my introduction of this topic, the programmer assumed the subscription-id would always be unique. But as I’ve proven now, it is possible (at least for a short time of 15 seconds) to have two subscriptions, having the same subscription-id, running twice on (at least) two connections, having different ids. Is this intended? If yes, is at least a combination of connection-id and subscription-id intended to be unique server-wide?

EDIT:

A small update: This happens on every reconnect. It happens if I switch between two networks having the same public IP address and even when loosing my only network connection and reconnecting to the same network again later. But then the closing of the subscription on the old connection is closed some seconds after the tab is closed. Looks like the browser is performing some cleanup here …

1 Like