Manual Client Reset Data Recovery - Node.js SDK

Track Changes by Object Strategy

The track changes by object manual client reset data recovery strategy lets you recover data already written to the client realm file but not yet synced to the backend.

In this strategy, you add a "Last Updated Time" to each object model to track when each object last changed. We'll watch the to determine when the realm last uploaded its state to the backend.

When backend invokes a client reset, find objects that were deleted, created, or updated since the last sync with the backend. Then copy that data from the backup realm to the new realm.

The following steps demonstrate implementing the process at a high level:

1. Client reset error: Your application receives a client reset error code from the backend.

2. Strategy implementation: The SDK calls your strategy implementation.

3. Close all instances of the realm: Close all open instances of the realm experiencing the client reset. If your application architecture makes this difficult (for instance, if your app uses many realm instances simultaneously in listeners throughout the application), it may be easier to restart the application. You can do this programmatically or through a direct request to the user in a dialog.

4. Move the realm to a backup file: Call the Realm.App.Sync.initiateClientReset() static method. This method moves the current copy of the client realm file to a backup file.

5. Open new instance of the realm: Open a new instance of the realm using your typical sync configuration. If your application uses multiple realms, you can identify the realm experiencing a client reset from the backup file name.

6. Download all realm data from the backend: Download the entire set of data in the realm before you proceed. This is the default behavior of the SyncConfiguration object.

7. Open the realm backup: Use the error.config object passed as an argument to the SyncConfiguration.error callback function.

8. Migrate unsynced changes: Query the backup realm for data to recover. Insert, delete or update data in the new realm accordingly.

const DogSchema = {
  name: "Dog",
  properties: {
    name: "string",
    age: "int?",
    lastUpdated: "int",
  },
};

const config = {
  schema: [DogSchema],
  sync: {
    user: app.currentUser,
    partitionValue: "MyPartitionValue",
    clientReset: {
      mode: "manual",
    },
    error: handleSyncError, // callback function defined later
  },
};

const LastSyncedSchema = {
  name: "LastSynced",
  properties: {
    realmTracked: "string",
    timestamp: "int?",
  },
  primaryKey: "realmTracked",
};
const lastSyncedConfig = { schema: [LastSyncedSchema] };
const lastSyncedRealm = await Realm.open(lastSyncedConfig);
lastSyncedRealm.write(() => {
  lastSyncedRealm.create("LastSynced", {
    realmTracked: "Dog",
  });
});

// Listens for changes to the Dogs collection
realm.objects("Dog").addListener(async () => {
  // only update LastSynced if sync session is connected
  // and all local changes are synced
  if (realm.syncSession.isConnected()) {
    await realm.syncSession.uploadAllLocalChanges();
    lastSyncedRealm.write(() => {
      lastSyncedRealm.create("LastSynced", {
        realmTracked: "Dog",
        timestamp: Date.now(),
      });
    });
  }
});

async function handleSyncError(_session, error) {
  if (error.name === "ClientReset") {
    const realmPath = realm.path; // realm.path will not be accessible after realm.close()
    realm.close(); // you must close all realms before proceeding
    // pass your realm app instance and realm path to initiateClientReset()
    Realm.App.Sync.initiateClientReset(app, realmPath);
    // Redownload the realm
    realm = await Realm.open(config);
    const oldRealm = await Realm.open(error.config);
    const lastSyncedTime = lastSyncedRealm.objectForPrimaryKey(
      "LastSynced",
      "Dog"
    ).timestamp;
    const unsyncedDogs = oldRealm
      .objects("Dog")
      .filtered(`lastUpdated > ${lastSyncedTime}`);
    // add unsynced dogs to synced realm
    realm.write(() => {
      unsyncedDogs.forEach((dog) => {
        realm.create("Dog", dog, "modified");
      });
    });
    // delete dogs from synced realm that were deleted locally
    const syncedDogs = realm
      .objects("Dog")
      .filtered(`lastUpdated <= ${lastSyncedTime}`);
    realm.write(() => {
      syncedDogs.forEach((dog) => {
        if (!oldRealm.objectForPrimaryKey("Dog", dog._id)) {
          realm.delete(dog);
        }
      });
    });
    // make sure everything syncs and close old realm
    await realm.syncSession.uploadAllLocalChanges();
    oldRealm.close();
  } else {
    console.log(`Received error ${error.message}`);
  }
}

Alternative Strategies

Possible alternate implementations include:

• Overwrite the entire backend with the backup state: With no "last updated time" or "last synced time", upsert all objects from the backup realm into the new realm. There is no way to recovered unsynced deletions with this approach. This approach overwrites all data written to the backend by other clients since the last sync. Recommended for applications where only one user writes to each realm.

• Track changes by field: Instead of tracking a "last updated time" for every object, track the "last updated time" for every field. Update fields individually using this logic to avoid overwriting field writes from other clients with old data. Recommended for applications with many fields per-object where conflicts must be resolved at the field level.

• Track updates separately from objects: Instead of tracking a "last updated time" in the schema of each object, create another model in your schema called Updates. Every time any field in any object (besides Updates) updates, record the primary key, field, and time of the update. During a client reset, "re-write" all of the Update events that occurred after the "last synced time" using the latest value of that field in the backup realm. This approach should replicate all unsynced local changes in the new realm without overwriting any fields with stale data. However, storing the collection of updates could become expensive if your application writes frequently. Recommended for applications where adding "lastUpdated" fields to object models is undesirable.