Ghost Data Syncing

The issue is that even though data has been deleted from both Atlas as well as locally, old data continues to reappear and sync. I have deleted the local files and terminated sync in the console and at that point, there is no local data. As soon as Sync is Enabled in the console, data sync’s (two objects) even though there is no data showing in the console.

Here’s a screenshot of the collection that previously had a couple of objects but as you can see, there is currently no data

When the app is run, the local Realm files are created and contain no data as expected. However, as soon as Sync is Enabled in the console, it appears that the old ‘ghost’ data is pushed to the app.

I am seeing this message in the console log but it’s not clear if this is indicating the client is pushing data UP to the server or if the server is pushing old deleted data to the client.

Source:

Write originated from MongoDB
Logs:
[
  "Upload message contained 2 changeset(s)",
  "Integrating upload required conflict resolution to be performed on 0 of the changesets",
  "Latest server version is now 36"
]
Partition:

Order Tracker
Write Summary:
{
  "OrderClass": {
    "deleted": [
      "60bb92c3a654cddf5736c5fb",
      "60bb893757d59169fcdae14d"
    ]
  }
}

The local files were manually deleted when the app was not running so this isn’t cached data.

Any ideas?

Hi, would you mind sharing your application URL (App Services) or just the app_id string that the console provides to you. Both are safe to send, but if you prefer, my email is tyler.kaye@mongodb.com. I should be able to decipher what is going on hopefully by looking at your logs.

The UI logs you are sharing here suggest that 2 objects were deleted by a MongoDB user and those writes are being replicated to Sync. Can you confirm that you are terminating sync (in the UI which gives you a warning), waiting 1-2 minutes, enabling sync, and then this is happening? If so I can take a look to see what might be going on.

Thanks,
Tyler

1 Like

Thanks @Tyler_Kaye

Here’s the URL

App Services

I am the sole user and the only objects (two of them) were deleted in the console when the app was not running. The local files were manually deleted so there should be no data to sync that originates locally.

Yes, sync was terminated in the console, I waited the normal 1-2 minutes and the enabled sync and the files appeared locally the next time the app was run.

One fun little additional nugget of info:

Since I drafted this email yesterday the app has not been used - I am the only person that has the app. There were no objects showing in the console yesterday per my screen shot above.

This morning I log into the console to get that URL I posted above and by chance, I checked that same collection and now it has an object - it just appeared out of the blue.

I checked the console and I see activity - none of it was app generated so it’s not clear (to me) what that activity means or why it’s there since there are no users and the app is not running. It’s probably server related but why would an object suddenly appear?

Hi, looking at your app now. It does seem like there is activity coming from the cluster itself. Sync opens a changestream to your synced collections to send down any changes made (updates, inserts, replaces, deletes) by any MongoDB users (via the Atlas Data Explorer / Drivers / Shell). You can tell that the write that you mention is created in Atlas/MongoDB and inserted into sync because the log says that “Write originated from MongoDB”. Can you confirm that no one else is writing to these collections? Because that is what it seems like is happening which is “works as designed”, but if not I can dig deeper into our logging for your application.

Thanks,
Tyler

@Tyler_Kaye

I can absolutely guarantee there are literally no other users or anyone reading or writing data. I hold the source code and this is not a published app so nobody has it.

The app has not been used since my original post.

Ok, I will take another look now, but I was not suggesting that another app was inserting the data but rather that someone was inserting data into the MongoDB collection, which can be done from any Shell/Driver/Atlas-UI

I see. Nobody else has access to the account or console.

Hey Jay, I took a look at the logs as well and I think I can explain this. When you reset sync, it doesn’t clear the data in the backing collections it just resets the sync history and builds up a synthetic history from the existing state on the server. Expanding the log that says “Write originated from MongoDB” which is an unexpected write from your app’s perspective you can see the object id (60c0c6b0203ccf72b42d2363). Looking further down through the logs, you can see that this object id actually originated from a previous write from your app a day earlier. So it looks like this object was written by the original sync history after you deleted everything from the console. Does that make any sense? If not, at what point did you delete the data from the console, before/during/after sync was disabled?

1 Like

Yes, I would agree it was from a previous write from two days ago - after that two other objects where written. The first object never appeared in the console->collections but the two following ones did which lead me to just blowing out everything and starting over.

The sequence I always follow to reset and clear everything is the same. These steps are required any time there’s a destructive change to the models so it happens frequently (and is really overly complex might I add)

  1. Quit App and restart Mac (ensures Realm has NO connection hanging around)
  2. Delete all local files
  3. Log into console, Atlas->collection and delete data

then

  1. Realm->Select the app
  2. Select the Class->Remove configuration
  3. Agree to removing everything
  4. Terminate sync, wait 2 minutes
  5. Reenable sync

From there, we are usually good to go; we can start the app, the fresh object models are created locally and then shortly after the schema appears in the console.

However, in this case, we started the app and had two objects sync down from the server (the ghost objects)

Then, after crafting the initial post here, and then doing that entire process again yesterday (you can see that in the logs), that object you’re referring to (60c0c6b0203ccf72b42d2363 ) appeared in the console (Collections)

The app has not been run so I don’t know where the data is coming from.

@James_Stone

We have stepped away for a few days, came back and deleted everything via the console twice, and the ghost objects appear to have abated. So… ?

Hi, I’ve been taking a look at your logs and wanted to post an update. Your termination procedure seems good, though I don’t think you should have to restart your Mac (that seems unnecessary), and if you want to simplify the process of making destructive changes, you can terminate sync, make any changes that you want, and then just enable sync (takes some steps / warnings out of the equation).

As for this issue you are seeing, I have been unable to reproduce this issue and I do not believe this to be a caching issue because there is no cache that lives between terminating and re-enabling sync. It still just looks to me like there is a document in MongoDB (60c0c6b0203ccf72b42d2363) and that document is modified by the Atlas UI / Data Explorer (those show up as Replaces) at Jun 10 10:12:05-04:00.

Has this been happening numerous times or just on a single occasion? It could be an issue with the Free Tier / perhaps there was a lot of replication lag, but that would only cause additional latency (and we cant see this per-user on free-tier clusters, only for dedicated clusters).

Jun 05 10:24:56-04:00
Write from a sync client: https://realm.mongodb.com/groups/5ee10c5ab73ba7359e3b9fa1/apps/5f8afc185d3fe2e9bf73a7da/logs?co_id=60bb8938fcb69e2f9abc2a63
{
  "OrderClass": {
    "inserted": [
      "60bb893757d59169fcdae14d"
    ]
  }
}


Jun 05 11:05:39-04:00
Write from a sync client: https://realm.mongodb.com/groups/5ee10c5ab73ba7359e3b9fa1/apps/5f8afc185d3fe2e9bf73a7da/logs?co_id=60bb92c12cb8623cdf9b868c
{
  "OrderClass": {
    "inserted": [
      "60bb92c3a654cddf5736c5fb"
    ]
  }
}


Jun 09 9:48:32-04:00
Write from a sync client: https://realm.mongodb.com/groups/5ee10c5ab73ba7359e3b9fa1/apps/5f8afc185d3fe2e9bf73a7da/logs?co_id=60c0c6b0af199486503ae04c
{
  "OrderClass": {
    "inserted": [
      "60c0c6b0203ccf72b42d2363"
    ]
  }
}


Jun 09 9:49:56-04:00
Write from the translator: https://realm.mongodb.com/groups/5ee10c5ab73ba7359e3b9fa1/apps/5f8afc185d3fe2e9bf73a7da/logs?co_id=60c0c704fb915d82bea7dafe
{
  "OrderClass": {
    "deleted": [
      "60bb92c3a654cddf5736c5fb"
    ]
  }
}

Jun 09 9:53:59-04:00
Write from a sync client: https://realm.mongodb.com/groups/5ee10c5ab73ba7359e3b9fa1/apps/5f8afc185d3fe2e9bf73a7da/logs?co_id=60c0c7f7af199486504eb917
{
  "OrderClass": {
    "inserted": [
      "60c0c7f6e7fd1cc2012873e7"
    ]
  }
}

Jun 09 10:17:41-04:00
Write from the translator: https://realm.mongodb.com/groups/5ee10c5ab73ba7359e3b9fa1/apps/5f8afc185d3fe2e9bf73a7da/logs?co_id=60c0cd85af19948650635082
{
  "OrderClass": {
    "deleted": [
      "60bb92c3a654cddf5736c5fb",
      "60bb893757d59169fcdae14d"
    ]
  }
}



Jun 10 10:12:05-04:00
Write from the translator: https://realm.mongodb.com/groups/5ee10c5ab73ba7359e3b9fa1/apps/5f8afc185d3fe2e9bf73a7da/logs?co_id=60c21db5d5e92f62ef7ff6f7
{
  "OrderClass": {
    "replaced": [
      "60c0c6b0203ccf72b42d2363"
    ]
  }
}

Blockquote

@Tyler_Kaye Thanks for looking into this. I didn’t want this to turn into a specific tech support thing but was hoping others who have experienced something like this might benefit from the process.

I am the only one who has the app and has access to the console so those changes were not don’t by me on the client side. It has happened before but resolved itself within a few hours but in this case those objects just kept showing up. In fact, as a test, I opened a brand new Mac that has never been used, created a new user an dropped the app on it and ran it and the ghost objects appeared soon after, even through nothing was showing in the console (as previously mentioned).

At this point it has resolved itself and I cannot duplicate it at this time either. Let’s close this out and re-open/file a bug report if I can duplicate in the future.

Thanks for all your help.