2.0.0-rc.13 async isPending derivation makes rendered memo values disagree

[GabbeV]

Describe the bug

Two JSX expressions read the same async memo, gate(). After an update, one displays 200 while the other still displays 100 for about three seconds.

The second expression also reads an async derivation of isPending(source). Retaining its previous pending value while the correction waits is understandable, but this also leaves its ordinary gate() read disagreeing with the other visible expression.

Your Example Website or App

https://s.olid.uk/id/lg40u1dpQkC5mIUmTn_Grw

Steps to Reproduce the Bug or Issue

1. Wait for initialization (about three seconds), until both rows show false | 100.
2. Click Run.
3. After about 300ms, the first row shows true | 200 and the second shows true | 100.
4. The different right-hand values remain visible for about three seconds. Both rows eventually show false | 200.

Expected behavior

The two visible reads of the ordinary memo gate() should agree while this update is held or revealed. This does not require the pending boolean to immediately become false: the delayed pending correction can remain held without showing two different values of gate() at once.

Screenshots or Videos

No response

Platform

• OS: Linux
• Browser: Chromium 151.0.7922.173
• Solid: 2.0.0-rc.13; also reproduced with current next at e44b2e4.

Additional context

Verified with compiled JSX and connected DOM in both development and production, including builds of the current next runtime and JSX compiler. There are no imperative reads, latest() calls, or loading boundaries in this example.

Two controls remove the mismatch:

• Change the pending-true delay from 300 to 50, so the child resolves before its parents: both rows show true | 200 during the hold.
• Make slow synchronous by returning value instead of delay(...): both rows show false | 200 after the parent work resolves.

[GabbeV]

Retested after #3774, at next 1b9ceb6. The linked repro now breaks during initialization: it doesn't mount, so I can't confirm whether the original value disagreement is fixed.

This can be reduced to a memo over isPending(source) read before a second initially async memo:

import { createMemo, isPending } from "solid-js";
import { render } from "@solidjs/web";

const delay = <T,>(value: T, ms: number): Promise<T> =>
  new Promise(resolve => setTimeout(() => resolve(value), ms));

function App() {
  const source = createMemo(() => delay(10, 100));
  const gate = createMemo(() => delay(100, 200));
  const pending = createMemo(() => isPending(source));

  return <p>{`${pending()} | ${gate()}`}</p>;
}

render(() => <App />, document.getElementById("root")!);

Expected: false | 100 once the promises resolve. Actual: the paragraph remains unmounted, including after ten seconds. Both promises fulfill; there are no further updates or page errors.

Two controls mount normally:

• Read gate() first: `${gate()} | ${pending()}`.
• Inline the probe: `${isPending(source)} | ${gate()}`.

Reproduced in development and production using source builds of the runtime and the revision's own JSX compiler. The PR base, 41fdf96, mounts all three variants normally. A raw scheduled createRenderEffect(() => [pending(), gate()], ...) also receives no application callback after both promises settle, so this isn't limited to JSX mounting.

I haven't established whether this has the same underlying cause as the original split, but it blocks retesting that example as written. The memo/direct-probe and read-order controls seem useful for narrowing it down.