Should an async createMemo re-run when it updates its own reactive dependency?

[corluk]

Async createMemo with pagination keeps re-running when nextCursor is updated from the fetched result

Description

I'm testing the async createMemo behavior in Solid 2.0.

I have a paginated API where each response contains a nextCursor. The cursor is stored in a signal and is also used as a dependency of an async createMemo.

After each request, I update the cursor with the nextCursor returned by the API.

Something similar to:

const [cursor, setCursor] = createSignal<string | undefined>(undefined);

const albums = createMemo(async () => {
  const json = await fetchAlbums(cursor());

  setCursor(json.nextCursor ?? undefined);

  return json.data;
});

Because cursor() is read inside the memo, changing it after the request causes the memo to run again.

As a result, the behavior becomes:

cursor = undefined
↓
fetch page 1
↓
setCursor(page2Cursor)
↓
memo reruns
↓
fetch page 2
↓
setCursor(page3Cursor)
↓
memo reruns
↓
...
↓
nextCursor = null

So simply reading the first result ends up fetching all pages until the API returns nextCursor: null.

Question

Is this the expected behavior for async createMemo in Solid 2.0?

I understand that cursor() becomes a reactive dependency of the memo, so from the fine-grained reactivity perspective the reruns make sense.

However, since Solid 2.0 encourages using async createMemo directly for data fetching, I'm wondering whether updating a pagination signal as a consequence of the same request is expected to recursively invalidate the memo in this way.

Should pagination state instead always be updated outside of the memo, for example in response to an explicit "Next page" action?

Or is there a recommended Solid 2.0 pattern for this type of cursor-based pagination?

Expected behavior / clarification requested

I'm mainly looking for clarification on whether:

1. This recursive request behavior is intentional and expected.
2. Updating reactive state from an async memo that is also one of the memo's dependencies should be avoided.
3. There is a recommended pattern in Solid 2.0 for cursor-based pagination using async createMemo.

Environment

solid-js: 2.0.0-rc.x

[gitsult4n]

Expected, and in your exact snippet it is worse than "fetches all pages": it never stops.

json.nextCursor ?? undefined turns the final null back into undefined, which is the value the first page was fetched with, so the memo re-runs page 1 and the cycle restarts. I ran your code against a three-page fake API on 2.0.0-rc.3, and it just spins:

fetch #1 cursor=undefined
fetch #2 cursor=c2
fetch #3 cursor=c3
fetch #4 cursor=undefined
fetch #5 cursor=c2
...

So the answer to question 1 is yes, tracked reads work the same in an async memo, and to question 2 also yes, do not write a signal the memo itself reads. Solid says so directly on the server build, where the same code prints:

[SERVER_WRITE] Writing a signal on the server is deprecated and will become an error. Server render is pure:
state changes flow from async sources (promises, async iterables), never setters

For cursor pagination, let the cursor be an input driven by an action, and let the memo return the cursor instead of assigning it:

const [cursor, setCursor] = createSignal(undefined);
const [all, setAll] = createSignal([]);

const page = createMemo(async () => await fetchAlbums(cursor()));

createEffect(() => page(), (p) => setAll(prev => [...prev, ...p.data]));

const nextPage = () => {
  const p = untrack(() => { try { return page(); } catch { return null; } });
  if (p?.nextCursor) setCursor(p.nextCursor);
};

Same fake API, three clicks:

fetch #1 cursor=undefined   page ready {"data":["a1"],"nextCursor":"c2"}
fetch #2 cursor=c2          page ready {"data":["a2"],"nextCursor":"c3"}
fetch #3 cursor=c3          page ready {"data":["a3"],"nextCursor":null}
(no more pages)
accumulated: ["a1","a2","a3"]
TOTAL FETCHES: 3

The untrack matters only if you call nextPage from somewhere reactive; from a click handler there is no tracking scope to leak into. The try is for NotReadyError, which an async memo throws while the request is in flight.

Both runs are on solid-js 2.0.0-rc.3 under node with --conditions=browser, since the default node resolution picks the server build where the setter is inert.