[ryansolid]

Summary

Before: an async memo's first answer resolves, and in the same synchronous turn a plain write re-asks the memo. The promise reaction runs after the write, so the landing and the re-ask are processed in one flush, and the runtime treated the answer as never produced:

• If the write's notification had already marked the node dirty, the answer was dropped outright. The stale-answer guard that did this was meant for re-asks.
• Otherwise the answer landed staged, but the re-ask left the node pending and uninitialized. isPending gave it no verdict: it read false from the flush's probe, and the node never re-ran.
• An identity memo or a derived store over the memo never derived from the answer, so latest of either threw and the screen showed [ROOT-L]. Plain latest(m0) showed the answer.

The async generator found these on rc.20: pairs E2/E3 for [s0=2 m0=async(s0)] <span split[latest(m0)]> with steps t S6 s0=0 t, and the F-9 isPending case.

After: a first answer always lands. A node that is answered and re-asked in one flush gets the re-ask's verdict from isPending, which is true. A memo with no value of its own that is waiting on that answer derives from it once, then re-runs on the missed-wake latch and waits on the re-ask. This holds at any depth: identity(identity(m)) reads like m. Plain, identity-memo and derived-store reads now show the same screen.

That includes a reader whose input goes through latest() or a sync memo, where the landing's settle walk had already released the reader before the re-ask reached it. These were the E2 residual cases: generator 3289 #310 and 91501 #1993/#2609.

The 2026-10-30 ruling (Q1 = A) amends D-22's 2026-10-28 clause: a plain write that re-asks the memo carries the answer the same way an action's write does. RULES-DERIVED.md is updated, next to #4490's #4474 ruling in D-22, which stands as written. D-23 exception 1 now says that a node answered and then re-asked in the same flush is not a first load.

Same-tick screen vs the two-tick orders. Readers mounted in the tick where the answer lands and the write re-asks show l:2 p:true on their first pass, then l:3. That is the answer-first order's screen without its intermediate p:false frame. In the write-first order the answer arrives after the re-ask, so it is stale, and the fallback stays until l:3. D-22 as amended rules the same-tick case: "an async memo's first answer that lands in the same tick as a write to its input that a hold carries — an action's, or a plain write re-asking it — is held with it (D-4), and latest of it returns that answer while the plain read still throws (F-9); a Loading whose only read is latest of it shows the answer now (S-40)." D-23 exception 1 rules the verdict: such a node "is not a first load … isPending of it is true". No rule compares the same-tick screen with the write-first order.

How

• Landing. handleAsync keeps a first answer even when the node is dirty. The keep is gated on holdWorkHook, because only latest and isPending can tell such a node apart from one with no value. Plain-only bundles keep the old guard and pay 0 B.
• Serving. When read would throw on a pending node, a cold helper servesStaged decides whether to serve the staged first answer instead. read calls it behind observeFlightHook on the pending-throw path, and its own bytecode drops from 1,318 to 1,170 (next: 1,139). It serves only when:
  • the reader is a memo with no value that waits on the source the read parks on (that source is el itself, or the async el derives from at any depth);
  • or the reader carries the missed-wake latch;
  • or the landing released the reader (no longer pending);
  • and the reader is not a render effect, lane work, a verdict lane's pass (D-37), a held node, or a staged error.
• Once per flush. A reader is served at most once a flush (_x._served records the clock). Without that, a boundary's children memo that reads two Shows parking on the same re-asked memo was served, threw on the second read, parked again, and was served again, without end.
• Verdict. isPending (verdict.ts) treats a node answered and re-asked in one flush as pending.
• Seat table. The reader-seat table gains row D3', with the same conditions as servesStaged. The table is __TEST__ only, so dist is unchanged.

Size vs next @ d0fc285 (after #4471, #4479 and #4490), measured locally (linux), brotli / minified:

scenario	delta	cap
hello world (9,973 B), every other floor, every plain-only scenario	0 B minified	unchanged
page: live server components (frozen floor)	+101 / +227	38.91 → 38.96 KB; recorded minified 117,566 → 117,793 (Size-Exception)
signals: + isPending/latest	+90 / +231	11.19 → 11.28 KB
page: compiled live server components	+35 / +232	42.83 → 42.87 KB
page: live + router	+70 / +232	48.51 → 48.58 KB

All four are over the 20 B flag. The once-per-flush guard and the cold helper account for about +58 B minified of the total. The released-reader case adds +13.

Size-Exception: page: live server components 38.91 KB -> 38.96 KB (recorded minified 117,566 -> 117,793 B, +227 B): an answered-then-reasked first answer lands and is served once a flush, out of line, including to a reader its landing released; correctness (D-22 as amended 2026-10-30, F-9). The code sits behind the verdict engine's hooks, so the core and app floors do not move in minified size.

How did you test this change?

• New packages/signals/tests/answered-then-reasked-same-tick.test.ts covers the landing, the isPending verdict, and identity-memo (one and two levels deep) and derived-store reads.

• New packages/signals/tests/answered-then-reasked-released-reader.test.ts covers the released-reader shapes; all three fail without the fix.

• New packages/web/test/async-gen/same-tick-first-answer-reask.spec.ts and e2-released-reader.spec.ts replay the minimized generator scenarios.

• New packages/web/test/async-gen/reask-served-once-a-flush.spec.ts replays the hang in four variants (six [ROOT-L] screens). It hangs without the once-per-flush guard.

• Suites after merging next @ d0fc285:

  suite	passed	expected fail
  signals	6,065	17
  web	1,573	7

• The async generator with the seat shadow ran on seeds 3289, 7 and 91501, 3,000 cases each, pairs E1/E2/E3/E9, with a timeout as the hang guard. There were no hangs and no new mismatch classes. The E2 residual cases now pass. One non-settle screen changed: seed 7 DEV build seems to have O(n^2) in registerGraph name resolution for createSignal in onMount when using signals from props #1322 now shows latest(m1) of an identity memo the same as latest(m0) (parity).

• Two sources answered and re-asked in one tick (c = m1() + m2()) still lose the second answer; that is 2.0: two async sources answered and re-asked in one tick: the second answer is dropped, latest() of their memo throws #4495, which throws on next too.

Found by the async-gen rerun on rc.20 (group 5).

---

🤖 Generated with Claude Code

https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2

[changeset-bot]

🦋 Changeset detected

Latest commit: 80a6417

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 15 packages

Name	Type
@solidjs/signals	Patch
test-integration	Patch
@solidjs/web	Patch
@solidjs/babel-plugin	Patch
@solidjs/compiler	Patch
@solidjs/diagnostics	Patch
@solidjs/element	Patch
@solidjs/h	Patch
@solidjs/html	Patch
solid-js	Patch
@solidjs/universal	Patch
board-example	Patch
canvas-example	Patch
server-dbmon-example	Patch
todos-server-example	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Size (brotli, eager entry chunk)

scenario	head	vs base	minified vs base	minified vs recorded	cap		lazy chunks (not counted)
signals: core floor (createSignal/Memo/Effect/Root/flush)	7.41 KB	−3 B (−0.0%)	0 B	+15 B	7.43 KB	✅
signals: + createStore	14.96 KB	+4 B (+0.0%)	0 B	+6 B	14.97 KB	✅
signals: + isPending/latest	11.27 KB	+85 B (+0.8%)	+231 B	+231 B	11.19 KB	❌ over by 80 B
signals: + until/refresh (truth readers, no optimism)	8.05 KB	−6 B (−0.1%)	0 B	+2 B	8.06 KB	✅
app: render + one signal (the simple-app floor)	9.79 KB	+8 B (+0.1%)	0 B	+15 B	9.78 KB	⚠️ over by 8 B, 5 B minified headroom
app: hydrating (no stores) with Show/For/Loading/Errored/lazy	18.72 KB	−34 B (−0.2%)	0 B	0 B	18.74 KB	✅	lazy-page.js 0.04 KB
app: hydrating + every store primitive family	32.41 KB	−51 B (−0.2%)	0 B	0 B	32.48 KB	✅	lazy-page.js 0.04 KB
app: CSR with Show/For/Loading/Errored/lazy	13.45 KB	−5 B (−0.0%)	0 B	+9 B	13.47 KB	✅	lazy-page.js 0.04 KB
app: CSR, observe tier (same app on the observe artifacts)	15.19 KB	+6 B (+0.0%)	0 B	+9 B	15.20 KB	✅	lazy-page.js 0.04 KB
app: CSR, observe tier + attribution engine enabled	29.76 KB	+13 B (+0.0%)	0 B	+9 B	29.78 KB	✅	lazy-page.js 0.04 KB
app: compiled floor (one template, one text hole, one delegated click)	9.97 KB	−1 B (−0.0%)	0 B	+2 B	9.98 KB	✅
app: compiled CSR (JSX todo app: spread/merge/omit, events, class/style, keyed For, Show, Loading + lazy, store)	26.27 KB	−66 B (−0.3%)	0 B	+13 B	26.33 KB	✅	stats.js 0.18 KB
app: compiled hydrating (the same JSX todo app through hydrate(), compiled hydratable)	32.48 KB	+26 B (+0.1%)	0 B	+7 B	32.54 KB	✅	stats.js 0.20 KB
frames: eager client consumer (frames client + transport, lazy codec)	11.75 KB	0 B	0 B	0 B	11.77 KB	✅
page: base server components (hydrating + dynamic + frames + sf reference)	33.71 KB	+34 B (+0.1%)	0 B	+9 B	33.77 KB	✅	assets.js 0.78 KB, decode.js 7.09 KB, lazy-page.js 0.04 KB, regions.js 1.06 KB, trace.js 9.03 KB, wire.js 3.47 KB
page: live server components (base + live/GET + action + isPending/latest)	38.98 KB	+68 B (+0.2%)	+227 B	+245 B	38.91 KB	❌ over by 67 B	assets.js 0.78 KB, decode.js 7.09 KB, lazy-page.js 0.04 KB, regions.js 1.06 KB, trace.js 9.04 KB, wire.js 3.47 KB
page: compiled base server components (the base page as JSX: templates with class/style/attributes/events, For/Show; no spread)	35.66 KB	−53 B (−0.1%)	0 B	+9 B	35.72 KB	✅	assets.js 0.78 KB, decode.js 7.09 KB, regions.js 1.06 KB, sc-comments.js 0.20 KB, trace.js 9.00 KB, wire.js 3.47 KB
page: compiled live server components (the compiled base page + live/GET + action + isPending/latest)	42.92 KB	+56 B (+0.1%)	+232 B	+232 B	42.87 KB	❌ over by 46 B	eager (counted): web.js 22.95 KB; assets.js 0.78 KB, decode.js 7.09 KB, regions.js 1.07 KB, sc-comments.js 0.19 KB, trace.js 9.08 KB, wire.js 3.47 KB
page: base + router (base page + @solidjs/router: createRouter, two routes, preload, useNavigate)	41.27 KB	+155 B (+0.4%)	0 B	+7 B	41.25 KB	⚠️ over by 16 B, 13 B minified headroom	assets.js 0.78 KB, decode.js 7.09 KB, lazy-page.js 0.04 KB, regions.js 1.06 KB, server.js 1.03 KB, serverForms.js 3.57 KB, trace.js 9.02 KB, wire.js 3.48 KB
page: live + router (live page + @solidjs/router: createRouter, two routes, preload, useNavigate)	48.60 KB	+110 B (+0.2%)	+232 B	+232 B	48.51 KB	❌ over by 91 B	eager (counted): client.js 28.09 KB; assets.js 0.78 KB, decode.js 7.09 KB, lazy-page.js 0.04 KB, regions.js 1.07 KB, server.js 1.03 KB, serverForms.js 3.30 KB, trace.js 9.03 KB, wire.js 3.49 KB
server: floor (getRequestEvent + isServer)	1.27 KB	0 B	0 B	0 B	1.29 KB	✅
server: renderToString (the server-render floor)	22.79 KB	0 B	0 B	0 B	22.80 KB	✅

⚠️ Over the brotli cap within the minified allowance (passes)

• app: render + one signal (the simple-app floor): over brotli cap by 8 B; minified 26,754 B vs 26,739 B recorded with the cap (+15 B) — 5 B of the 20 B minified allowance left; +0 B minified over this PR's base
• page: base + router (base page + @solidjs/router: createRouter, two routes, preload, useNavigate): over brotli cap by 16 B; minified 125,477 B vs 125,470 B recorded with the cap (+7 B) — 13 B of the 20 B minified allowance left; +0 B minified over this PR's base

❌ Fails the gate

• signals: + isPending/latest: over brotli cap by 80 B; minified 31,071 B vs 30,840 B recorded with the cap (+231 B) — 211 B past the 20 B minified allowance; +231 B minified over this PR's base. real growth: reduce it, or raise the cap and its recorded minified in this PR with a reason (frozen floors need Size-Exception:)
• page: live server components (base + live/GET + action + isPending/latest): over brotli cap by 67 B; minified 117,811 B vs 117,566 B recorded with the cap (+245 B) — 225 B past the 20 B minified allowance; +227 B minified over this PR's base. real growth: reduce it, or raise the cap and its recorded minified in this PR with a reason (frozen floors need Size-Exception:)
• page: compiled live server components (the compiled base page + live/GET + action + isPending/latest): over brotli cap by 46 B; minified 125,956 B vs 125,724 B recorded with the cap (+232 B) — 212 B past the 20 B minified allowance; +232 B minified over this PR's base. real growth: reduce it, or raise the cap and its recorded minified in this PR with a reason (frozen floors need Size-Exception:)
• page: live + router (live page + @solidjs/router: createRouter, two routes, preload, useNavigate): over brotli cap by 91 B; minified 143,219 B vs 142,987 B recorded with the cap (+232 B) — 212 B past the 20 B minified allowance; +232 B minified over this PR's base. real growth: reduce it, or raise the cap and its recorded minified in this PR with a reason (frozen floors need Size-Exception:)

_{Bundled with Rolldown (what Vite ships), brotli q11, decimal KB. A scenario fails only when it is over its brotli cap and its minified size is more than 20 B over the minified recorded with the cap; over the cap within that allowance is brotli layout noise and passes with a warning. Caps and their recorded minified in scripts/size/scenarios.js; the floor and page caps in floor-caps.json are frozen (lower only, or Size-Exception: in the PR body). npm run ratchet lowers caps per RC; it never raises one (scripts/size/README.md).}

[coveralls]

Coverage Report for CI Build 41109677117

Warning

Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes.
Quick fix: rebase this PR. Learn more →

Coverage remained the same at 78.1%

Details

• Coverage remained the same as the base build.
• Patch coverage: No coverable lines changed in this PR.
• No coverage regressions found.

Uncovered Changes

No uncovered changes found.

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	1362
Covered Lines:	1125
Line Coverage:	82.6%
Relevant Branches:	1090
Covered Branches:	790
Branch Coverage:	72.48%
Branches in Coverage %:	Yes
Coverage Strength:	29.76 hits per line

---

💛 - Coveralls

[codspeed]

Merging this PR will degrade performance by 8.84%

2 warnings

⚠️ 4 benchmarks are dominated by system calls

System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.

Learn more about system calls

See affected benchmarks

⚠️ 2 benchmarks with a significant change ran on different hardware

Their base and head results were measured on machines with a different CPU, core count or memory, so the changes might not come from the code. Run base and head on the same runner type.

Learn more about Macro Runners

See affected benchmarks

❌ 2 regressed benchmarks
✅ 198 untouched benchmarks
⏩ 5 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
❌	arrow in template	11.1 ms	12.4 ms	-10.02%
❌	memo + sync render effect only (reference)	32 ms	34.7 ms	-7.64%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing claude/project-thread-x1ore2-reask-landing-answered (80a6417) with next (c8d6fd2)}

Footnotes

1. 5 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[ryansolid]

CodSpeed's two regressions are noise, not this change:

• arrow in template (−10.7%) is the known outlier on next's recorded baseline for that bench; every PR against this base shows it.
• spread store record × 500 (−7.4%) never reaches the code this PR touches. The only runtime change is one guard in the async landing path (async.ts), and that bench renders a spread of a plain store record with no async at all. CodSpeed also flags that base and head ran on different hardware for 7 of the changed benches.

The 5 "improvements" are the same runner swing in the other direction.

---

Generated by Claude Code

[ryansolid]

I don't think CodSpeed's −6.6% on spread store record × 500 comes from this PR. The new branch in read sits inside the path that runs only when the read node is pending, and the handleAsync change runs only when an async answer lands. This bench spreads a sync store record, so it reaches neither. The other four flagged benches moved the other way by 7–100%, which matches what #4463 and #4464 show against the same base (next 131ceb8): that base run was an outlier on several benches. I'm treating it as noise.

---

Generated by Claude Code