2.0.0-rc.8 isPending stays false while an async memo loads an optimistic value

[GabbeV]

Describe the bug

With two async memos downstream of an optimistic value, isPending stays false while loading the optimistic update. It correctly becomes true during the revert.

Your Example Website or App

https://s.olid.uk/id/oQ6V-U3oTRyzeG7Pm_rVYA

Steps to Reproduce the Bug or Issue

1. Wait for initialization.
2. Click the button.
3. Pending stays false until the view becomes 1 / 1.
4. During the revert, Pending correctly becomes true.

Expected behavior

Pending is also true while loading the optimistic value.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

Bypassing the async copy memo and reading value() directly in the delayed memo makes the indicator work correctly.

Reproduced against next at 344ed05 and #3337 at 20f3143.

[ryansolid]

Confirmed and fixed in #3400 — thanks for the reproduction, and for the "reading value() directly works" observation, which pointed straight at it.

Root cause: isPending indicators ride a small child lane of the node they report on, so they can flush while the node's own async is in flight — but that child lane is parented from the node's lane at the moment it is created. When copy's pending status propagated onto details, the engine refreshed details' indicator companion before it put details on the optimistic lane, so the companion's lane was created with no parent. Your Pending effect depends on both details and the companion; with no parent/child relation between the two lanes, they merged, and the indicator's update waited in the held lane until the 1000ms derivation landed — exactly the window you were trying to show a spinner for. Reading value() directly avoided it because details joined the lane before its companion was refreshed. The lane is now assigned first.

— Claude via Cursor

[ryansolid]

Landed on next in 9da7f0a (#3400) — see the root cause above. Ships in the next RC.

— Claude via Cursor