Meteor DDP issue

magyarosibotond · July 5, 2021, 11:43am

Hey all!

I’m having an issue with Meteor on one of the projects I’m working on and can’t really figure it out how to fix the behaviour.

Here’s the setup:

The client has a self-hosted Meteor instance (AFAIK) but I have no access of information about the version.
I’m building the iOS app that’s using the semi-official iOS client: GitHub - EngrAhsanAli/MeteorDDP: MeteorDDP is really helpful to integrate servers written in meteor (a framework written in javascript) using native Swift in iOS.. I saw the client pop up a couple of times.
The database is relatively small with 7-8 collections with a couple of entries per collection.

Since the iOS client lacks proper local persistence, the data has to be synced every time the app is restarted.

When the app starts I’m subscribing to all collections and update the documents accordingly (in memory) so the UI can subscribe to changes and update reactively.

While a web app works as expected I’ve noticed that the ready message is received before any added message which causes the UI to stop loading prematurely and list items appear one-by-one.

From my understanding Meteor should only send ready when an initial set of documents have syncronized.

When one or more subscriptions have finished sending their initial batch of data, the server will send a ready message with their IDs.

Is this expected? I’m I missing something?

Thanks!

mullojo · July 6, 2021, 4:04am

Meteor’s DDP ready message is sent when all the docs in a subscription are on the client. It seems you have the right understanding of how it works from your comments.

Of course as new docs are added to the database, in a published collection, you will see them show up on the client 1 at a time as you would expect.

One of the easiest ways to examine this behavior is to use the Meteor Dev Tools Evolved: Meteor DevTools Evolved - Chrome Web Store

magyarosibotond · July 6, 2021, 8:30am

Thanks for the clarification @mullojo!

It seems like the web client receives the chunks in the right order: sub -> added -> added -> ready, while the iOS client receives a ready right after subscribing.

Both clients have a valid session and just by looking at it, there’s no difference in the message structure nor the order of the messages. I’ll dig myself into it a bit more.

The only difference I’ve noticed is that the web client has an auto incrementing value for the subscription ids while the iOS client relies on UUIDs.