Documents Not Removed on Unsubscribe

[Data-Meister]

When mergebox is disabled then when you unsubscribe the docs are not removed. This could be undesirable e.g. if you have a logged-in only subscription and then you log out, this end the subscription - but the documents are still present. Only way to remove them is explicitly give that instruction from the publication.

Given what you've written in the docs - mergebox tracks what docs came from what subs - it sounds liek this might not be easy to fix. If so it might be good to update the readme to warn devs about this.

[mitar]

Hm, you are right.

[Data-Meister]

As a workaround I'm using an onStop callback on the subscription:

@subscribe "MyCollection", onStop : ->

  MyCollection._collection.remove({})

I also tried doing an @onstop() in the publication with @remove() but that didn't work - I guess that gets called too late.

[mitar]

I also tried doing an @onstop() in the publication with @remove() but that didn't work - I guess that gets called too late.

That is strange. Have you been removing correct Ids? What if you remember all IDs you ever added and then remove them?

[Data-Meister]

I remembered the specific IDs yes. I will check again to be sure.

[Data-Meister]

I used the following code:

@onStop =>
 
  @removed "MyCollection", myId

I tried putting @onstop() inside the @Autorun and outside the @Autorun. Unfortunately either way it does not work. It's quite simple to test in my case as I am only publishing one _id per sub.

I logged out all DDP messages received by the client when I log out. I see other publications sending me a "removed" message from other pubs - but not the @disableMergebox() pub. When I enable mergebox again I get removed messages fine.

I hear what you're saying - it is indeed surprising you can't call @remove() within @onstop() given that the server sends remove messages after the client sends an unsub message. Perhaps that is handled somehow by Mergebox on publication stop using something even more low-level than the low-level publication API? It could also be that onStop() is called after the remove messages have been sent so it's too late. Or maybe it could work in principal, but need to patch your library.

[mitar]

I think I have some vague memory of you not being able to call those added, removed and so on inside onStop because at that point subscription is already stopped. Try it with a normal subscription, for example to added a document in onStop and see if it sends a message, I do not think it will.

See here: https://github.com/meteor/meteor/blob/master/packages/ddp-server/livedata_server.js#L1267

[Data-Meister]

You're right self._deactivated = true is set just before the onStop callbacks are called so added, removed and so on will have no effect:

https://github.com/meteor/meteor/blob/master/packages/ddp-server/livedata_server.js#L1121

The method which sends remove messages when the publication is stopped is here:

https://github.com/meteor/meteor/blob/master/packages/ddp-server/livedata_server.js#L1142

For this to work the published ids should be in self._documents on the Subscription Object

I had a look at your code and I see you are doing something a little bit similar - writing entries to collectionView.documents

https://github.com/peerlibrary/meteor-control-mergebox/blob/master/server.coffee#L22

But this is setting docs on the SessionCollectionView not the Subscription.

This is the first time I've seen this code so not sure how the pieces all fit together. Do you think it would be possible (and desirable) to update the Subscription object as well as the SessionCollectionView?

[mitar]

For this to work the published ids should be in self._documents on the Subscription Object

But the whole point of this package is to not store information on the server about what is published. So this _documents is never populated.

So, try manually remembering which IDs you published and then call this code manually (which is code from removed) and let us see what happens:

    id = self._idFilter.idStringify(id);
    // We don't bother to delete sets of things in a collection if the
    // collection is empty.  It could break _removeAllDocuments.
    delete self._documents[collectionName][id];
self._session.removed(self._subscriptionHandle, collectionName, id);

But yes, a good question is what should be done. Maybe a better solution than to try to fix the server side (because the whole idea is that server side should not remember what it published) is that unsubscription on the client side is extended so that when you stop the subscription it cleans up the client side. So if you subscribed to a collection only to one publish function with disabled mergebox, then it is easy to remove subscriptions on the client: you just remove all documents. But if you subscribed to collection through multiple subscriptions and some of them without disabled mergebox, then it is trickier.

Maybe you can try to use this package to know which documents were published through a subscription and remove all of them on the client manually after unsubscribe.

[Data-Meister]

Hi Mitar, I'd love to fix this properly - thanks for the package link. However since I've found a workaround which works for my client I can't justify doing this on company time - so it might take a little while to get around to doing it. I may have some time in the next few weeks or over Christmas.

[mitar]

No worries! Thanks!

[mitar]

So I cannot reproduce this. We even have a test that once unsubscribe happens, client collection is emptied.