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

Activity

1. GabbeV commented on Oct 4, 2026

   

   GabbeV

   on Oct 4, 2026

   Author

   More actions

   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.
2. brenelz

   added a commit that references this issue on Oct 5, 2026

   fix(signals): a lane's pending leaf re-runs as the lane's work (solid…

   ...

   586b5f3
3. ryansolid

   added a commit that references this issue on Oct 6, 2026

   fix(signals): L2 lane takeover of held effects (#3766) and optimistic…

   ...

   2317623
4. ryansolid commented on Oct 6, 2026

   

   ryansolid

   on Oct 6, 2026

   Member

   More actions

   Fixed in #3812, merged to next as 2317623.

   A render effect that a lane took over from a held transaction now keeps running as the lane's work while it waits on the lane's flight, so the memo values it renders no longer disagree. @brenelz's mark from #3794 is part of the fix, credited as co-author. The fix also stops a pass that leaves the lane from keeping a hold with nothing behind it.

   — Claude via Cursor
5. ryansolid

   closed this as completedon Oct 6, 2026