`react-db@0.1.78` electric `createLiveQueryCollection` inconsistent data without `getKey`

[boyswan]

• [x ] I've validated the bug against the latest version of DB packages

Describe the bug

When using the latest react-db@0.1.78, createLiveQueryCollection with an electric collection returns inconsistent data. In my case, it returns 1/n items. On 0.1.77 it returns the full set.

const teamsWithUserCollection = createLiveQueryCollection({
  getKey: i => i.team.id,   //  <------ this is now required to fetch all data correctly
  query: (q) =>
    q
      .from({ team: teamCollection })
      .join({ user: userCollection }, ({ user, team }) => eq(user.id, team.user_id))
      .select(({ team, user }) => ({
        team: team,
        profile: user?.profile,
      }))
})

export const useTeams = () => {
  const { data, isLoading } = useLiveQuery(
    (q) => {
      return q.from({ teamWithUser: teamsWithUserCollection })
    }
     ...
  )

Adding getKey fixed the issue.

Additional context

Testing all latest packages, but previous react-db@0.1.77 works without getKey

"@tanstack/db": 0.6.0
"@tanstack/electric-db-collection": 0.2.42
# "@tanstack/react-db": 0.1.78
"@tanstack/react-db": 0.1.77

[boyswan]

An LLM diagnosis:

 @tanstack/db collections map result objects to pipeline keys using a WeakMap<object, key>. When a downstream useLiveQuery subscribes to a collection, the subscription emits change events containing the
 collection's items. These items pass through sendChangesToInput, which calls getKey(change.value) to look up each item's key in the WeakMap.

 The problem: collection.get() enriches stored items by spreading them into new objects with virtual properties ($synced, $origin, $key, $collectionId). This enriched copy is a different object reference from the
 one stored in the WeakMap. getKey(enrichedCopy) returns undefined, and when multiple items all resolve to undefined, they collide — the query returns 1 item instead of N.

 Every change event already carries the correct key as change.key — and every other function in the same file (filterDuplicateInserts, splitUpdates) already uses it. The fix is to prefer change.key over
 re-deriving via getKey(change.value):

 # dist/esm/query/live/utils.js
 -    const key = getKey(change.value);
 +    const key = change.key !== undefined ? change.key : getKey(change.value);

The fix being

--- a/dist/esm/query/live/utils.js
+++ b/dist/esm/query/live/utils.js
@@ -113,7 +113,7 @@ function buildQueryFromConfig(config) {
 function sendChangesToInput(input, changes, getKey) {
   const multiSetArray = [];
   for (const change of changes) {
-    const key = getKey(change.value);
+    const key = change.key !== undefined ? change.key : getKey(change.value);
     if (change.type === `insert`) {
       multiSetArray.push([[key, change.value], 1]);
     } else if (change.type === `update`) {

This seems to work when patching locally - but it would probably be best verified by someone who has a genuine understanding of the internals!

[kevin-dp]

The regression was introduced by PR #1213 ("Virtual props implementation"). The key change is in packages/db/src/collection/changes.ts — the emitChangesOrBatchEvents method now enriches every change message before emitting:

const enrichedEvents = rawEvents.map((change) => this.enrichChangeWithVirtualProps(change))

enrichChangeMessage calls enrichRowWithVirtualProps which creates a new object via spread:

return { ...row, $synced, $origin, $key, $collectionId }

This breaks the WeakMap-based default getKey in CollectionConfigBuilder (line 229-230):

getKey: this.config.getKey || ((item) => this.resultKeys.get(item) as string | number)

The resultKeys WeakMap stores the original D2 output objects, but downstream subscribers now receive enriched copies — different object references — so the WeakMap lookup returns undefined for all items. All items collide on key undefined, resulting in 1/N items.

The exact bug path for this bug report:

1. teamCollection + userCollection (Electric, field-based getKey — fine)
2. teamsWithUserCollection = createLiveQueryCollection(...) with default (WeakMap) getKey
3. useLiveQuery subscribes to teamsWithUserCollection
4. teamsWithUserCollection emits changes with enriched (spread-copied) values
5. sendChangesToInput calls teamsWithUserCollection.config.getKey(enrichedValue) → WeakMap miss → undefined
6. All items map to key undefined → only 1 survives

getKey is also used in other places. There are at least 3 call sites that can fail:

1. sendChangesToInput (utils.ts:227) — the reported bug. Calls getKey(change.value) on enriched values from subscriptions.

2. getKeyFromItem on enriched objects (collection-config-builder.ts:1719) — parentCollection.get() now returns enriched objects, then getKeyFromItem is called on them. If the parent is a live query collection with default WeakMap getKey, this fails too. This affects the includes / nested subquery re-emit path.

3. getKeyFromItem at line 933 — this one is actually safe because resultKeys.set(value, key) is called on line 915 with the same value object just before it's used.

Preferring change.key over getKey(change.value) is correct for case 1, but doesn't address case 2. A more robust fix would be to either:

• Have enrichChangeMessage update the WeakMap with the enriched copy too
• Or make the default getKey fall back to item.$key (which the enrichment already sets)

The $key fallback seems cleanest since virtual props were designed to carry this info:

getKey: this.config.getKey || ((item) => this.resultKeys.get(item) ?? item.$key)

That would fix both paths without touching every call site.