On change being triggered with remove on start subscription start

[tiagocorreiaitcenter]

Im using simpleddp on a react-native application, I start the subscriptions with an onChange every time the app is opened, i'm having a strange behavior that when I start the subscriptions I receive N onChange events of removed, that are followed by the same N events but for added, so basically its removing and adding the same content every time I open the app, I tried multiple things, such as for example, remove all subs, changeListeners and even calling clearData before starting the subscriptions, but I do still receive the on change events, any idea what might be causing it?

[Gregivy]

Hello! It is difficult to say something right now, could you provide your simpleddp version and a source code with such behavior?

[tiagocorreiaitcenter]

I'm using the latest version @Gregivy being it 2.2.4 About the source code itself, if you really feel like that's necessary I can create a demo or something similar, but the behavior happens with any subscription

[tiagocorreiaitcenter]

@Gregivy can you provide some info about how you store the data that comes from the server? do you just keep it in memory? Also, how would you ensure that once you start your server all the previous data doesn't exists? thanks

[Gregivy]

Hi @tiagocorreiaitcenter. I think you faced the lost connection behavior. When connection drops or something similar happens Meteor forgets your ddp session, so we have to remove all the data on the reconnection and for consistency simpleddp sends this fake remove events. There is no way to avoid this using standart meteor ddp system if we want the data to be consistent with server. If these messages somehow create difficulties I can add special labels for such messages in future version of simpleddp so you can filter them easily.

[Gregivy]

@tiagocorreiaitcenter this is the part of the code where cleaning is happening https://github.com/Gregivy/simpleddp/blob/master/src/simpleddp.js#L99

[tiagocorreiaitcenter]

@Gregivy Those labels would help really a lot, we have requested associated with certain subscriptions, and receiving a remove and add to the same data right after triggers a lot of requests from our side, which to be honest I feel like is making the app slower, I will try to give a look to the code and see if I can patch a quick fix or maybe a full time solution and if so I will open a pull request, thanks once again

[tiagocorreiaitcenter]

@Gregivy Sorry to bother again( I should close this issue), I found the issue to my problem, seems that every time the connection is established the subscriptions are restarted? so if I open the app it connects to the server and then restarts the subs, which causes the first remove followed by the add on the listeners.

I start the connection in a file and I don't wait at all for the server to be ready to subscribe to a collection, so probably what happens behind the scenes, is the server is called to be start, mean time the subscription starts, server is ready, subscription gets ready and then the server calls the restart subs? Is this the normal behavior? It's strange having the listeners/subscriptions restarting right after the first connection to the server

[Gregivy]

Hello @tiagocorreiaitcenter, sorry for the delay.

Yeah it works exactly as you said, if you don't wait for the server connection, subscriptions will fail at the same time, then when server establishes connection - every subscription will resubscribe as default behavior.

[hems]

I'm having a very similar behaviour on my side, but suspect in my case the subscriptions get restarted when the user logs in? Is that possible @Gregivy?

On my case my code sample is:

      const notificationsUnreadSub = server.subscribe("notifications.unread");
      await notificationsUnreadSub.ready();

      const notificationsCursor = server.collection('notifications')
        .reactive()

      const onChange = (data) => {
        console.log("got data ->", data)
      }
      
      notificationsCursor.onChange(onChange)

I would expect onChange to not be called right away because I waited for the subscription to be ready, but instead, I get exactly the same behaviour described by @tiagocorreiaitcenter

perhaps i should re-structure my app so it connects and logs-in before doing any subscription

[Gregivy]

@hems Yes, if the user logs in or out the subscriptions needs to be restarted.

[hems]

@hems Yes, if the user logs in or out the subscriptions needs to be restarted.

Thanks for letting me know, i'll make sure my application works considering that information.

---

A couple things i thought that are:

• instead of "fake remove" and "adds again" it could first "merge" the data, and then dispatch "remove", "updated" and "added" accordingly? OR
• When creating subscription there could be an option where you say that you don't need that specific subscription to be restarted on log in / log out, for instance, for public data?

Of course this is far more complicated and could introduce extra bugs and complications, still i thought it might contribute somehow to this topic.

Thanks again for your library and support.