Repeated remote updates can leave accessed linksMode hasMany relationships stale

[alexraputa]

Summary

When a linksMode hasMany relationship has already been accessed/materialized, a later remote update can change the canonical relationship state without resynchronizing the materialized local state when there is no local mutation to reconcile.

Reproduction

1. Seed two user records and two pet records with user.pets <-> pet.owner.
2. Start from:
   • user:1.pets = ["1"]
   • user:2.pets = ["2"]
3. Access user1.pets so the linksMode hasMany is materialized.
4. Send PATCH /api/user/1 updating pets to [{ type: "pet", id: "1" }, { type: "pet", id: "2" }].
5. Send another PATCH /api/user/1 updating pets to [{ type: "pet", id: "1" }].

Expected

After each remote update, if there are no local additions, removals, or local reordering to preserve, the materialized linksMode hasMany should match the canonical remote state.

Actual

The canonical/inverse state updates, but the already-accessed materialized hasMany can remain stale after repeated remote updates.

For example, after the second PATCH, pet2.owner is cleared but user1.pets can still contain ["1", "2"] instead of ["1"].

Suspected Area

This looks like a policy bug in replaceRelatedRecordsRemote:

warp-drive/warp-drive-packages/core/src/graph/-private/operations/replace-related-records.ts

Line 178 in b3372e5

function replaceRelatedRecordsRemote(graph: Graph, op: ReplaceRelatedRecordsOperation, isRemote: boolean) {

The relevant case is:

• hasMany
• linksMode
• relationship already accessed/materialized
• remote membership changed
• no local mutation is present

---

Environment

• WarpDrive: 5.8.1
• Node: 25.8.0
• pnpm: 10.31.0

[runspired]

@alexraputa what does the normalized api response look like after each patch?

[alexraputa]

@runspired failing test #10495