Mention our experience so far

web/packages/base/kv.ts

@@ -10,6 +10,26 @@ import log from "./log";
  *
  * The "kv" database consists of one object store, "kv". Keys are strings.
  * Values can be arbitrary JSON objects.
+ *
+ * [Note: Avoiding IndexedDB flakiness by avoiding indexes]
+ *
+ * Sporadically, rarely, but definitely, we ran into issues with IndexedDB
+ * losing data. e.g. saves from the ML web worker would complete successfully,
+ * but the saves would not reflect on the main thread, and that data would just
+ * get lost when the app would refresh.
+ *
+ * I'm not sure where the problem lay - in our own code, in the library that we
+ * are using (idb), within IndexedDB itself, or in Electron/Chrome's
+ * implementation of it (these cases all came up in the context of the ML code
+ * that only ran in our desktop app).
+ *
+ * A piece of advice I randomly ran across on the internet was to keep it very
+ * simple, and avoid all indexes. I also recalled that we did not see such
+ * issues with our older (but now unmaintained) library, localforage, which also
+ * doesn't use any indexes, and just has a flat single-store schema.
+ *
+ * So this may be superstition, but for now the approach I'm taking is to use
+ * IndexedDB as a key value store only.
  */
 interface KVDBSchema extends DBSchema {
     kv: {

web/packages/new/photos/services/ml/db.ts

@@ -35,14 +35,8 @@ import type { CGroup } from "./people";
  * The face clustering related object stores are the following:
  *
  * -   "face-cluster": Contains {@link FaceCluster} objects, one for each
- *     cluster of faces that either the clustering algorithm produced locally or
- *     were synced from remote. It is indexed by the cluster ID.
- *
- * -   "cluster-group": Contains {@link CGroup} objects, one for each group of
- *     clusters that were synced from remote. The client can also locally
- *     generate cluster groups on certain user interactions, but these too will
- *     eventually get synced with remote. This object store is indexed by the
- *     cgroup ID.
+ *     cluster of faces that either the clustering algorithm produced locally.
+ *     It is indexed by the cluster ID.
  */
 interface MLDBSchema extends DBSchema {
     "file-status": {
@@ -397,14 +391,6 @@ export const getFaceClusters = async () => {
     return db.getAll("face-cluster");
 };
 
-/**
- * Return all cluster group entries (aka "cgroups") present locally.
- */
-export const getClusterGroups = async () => {
-    const db = await mlDB();
-    return db.getAll("cluster-group");
-};
-
 /**
  * Replace the face clusters stored locally with the given ones.
  *
@@ -419,27 +405,3 @@ export const setFaceClusters = async (clusters: FaceCluster[]) => {
     await Promise.all(clusters.map((cluster) => tx.store.put(cluster)));
     return tx.done;
 };
-
-/**
- * Update the cluster group store to reflect the given changes.
- *
- * @param diff A list of changes to apply. Each entry is either
- *
- * -   A string, in which case the cluster group with the given string as their
- *     ID should be deleted from the store, or
- *
- * -   A cgroup, in which case it should add or overwrite the entry for the
- *     corresponding cluster group (as identified by its {@link id}).
- */
-// TODO-Cluster delete me
-export const applyCGroupDiff = async (diff: (string | CGroup)[]) => {
-    const db = await mlDB();
-    const tx = db.transaction("cluster-group", "readwrite");
-    // See: [Note: Diff response will have at most one entry for an id]
-    await Promise.all(
-        diff.map((d) =>
-            typeof d == "string" ? tx.store.delete(d) : tx.store.put(d),
-        ),
-    );
-    return tx.done;
-};