Simperium backend stops syncing to IOS client with toggling value (heartbeat implementation)

[bayareacoder]

We use IOS client v0.8.17 and implement a heartbeat function in the app by toggling a Boolean between true and false every 5 seconds (CoreData makes this an NSNumber that toggles between 0 and 1 I believe). We detect the toggling value in our web app via your JS library as proof that the IOS client is online.
What we see is that after some time (can be a few days) the value is not toggling anymore although the IOS app is active. On the Simperium website the value is no longer toggling either so it seems an issue between IOS client and your backend.
There seem to be similar issue reports (e.g. #293) of sync stopping after certain conditions.
Is there a root cause of this & a solution, or another way to implement a heartbeat function?

[bayareacoder]

One more addition that may be useful: when on the same object we make a change to another attribute than the 'heartbeat' attribute from the web app (via JS client), this other attribute is correctly updated. Current code on IOS client does not change any other attribute so we cannot test if that syncing works still.

[jleandroperez]

Hello there @bayareacoder,

Simperium was really designed to isolate you from those details. Internally, it already has a heartbeat (check here).

If you still need to check the internal state, you could rely on this property to get the "Last Seen Time".

If the "Heartbeat Use Case" is to detect which clients are online (Web / iOS), you could, instead, try using presence, which is a way better approach. It's described in this tutorial, but long story short, you enable it via a REST call, and any objects you insert in a given bucket, will be deleted whenever a client disconnects.

Regarding the Out of Sync issues you mention, please, try enabling verbose logging, and check the logs whenever your app stops sync'ing.

If / when that happens, please, make sure to also check the last seen time (and perhaps the requiresConnection property as well).

Hope that helps!

[bayareacoder]

Thank you for the detailed reply!
Enable client detection on a bucket with a REST call seems exactly to cover what we need (as we have multiple IOS clients connecting under same login user presence wouldn't work). Seems we should be able to have each client create an object in that bucket that has some identifier attribute, then as long as client is online it will remain there, and our web app (another client under same user login) can check if all objects are there and if not figure out which one is missing from the identifier attribute. We will try this.

One thing we need to capture is an app crash in which case there will not be a call to the Simperium 'signout' method. Will the server remove these objects then as well - I assume yes since removal by the server relies on not receiving the heartbeat anymore you put in the connection? Pls confirm.

We've only seen our 'heartbeat' implementation stop syncing after a long time (sometimes days) so it's a bit difficult to capture the logs and find the exact time it happens.

Was there ever a resolution to #293 - the issue was never closed from 2 yrs ago?

[jleandroperez]

@bayareacoder awesome, glad to hear it was useful!

Whenever the client disconnects / signs out, the presence data should be cleared out, indeed.

Regarding #293, i'm afraid the issue was never really addressed. Nevertheless, it's a different scenario from yours. The backend side rejection was caused by a schema enforcement policy being tested (during development), and it's something that shouldn't happen in real-life usage.

If you ever manage to retrieve the verbose log for this glitch, please, feel to reopen this issue.

Thank you for helping us out!!