Repository navigation
fix(signals): a guess over a question in flight keeps the frame whole with a memo between the list and its binding (#4561) - #4572
Merged
Conversation
… with a memo between the list and its binding (#4561) #4558 kept a render effect in the frame's hold observing the flight a list guess was written over, but a derivation between the list and its binding (a memo, a mapArray) was served the guess as standing in for the flight, stopped waiting on it, and the binding followed it out of the hold: the frame committed `closed` beside the open answer's rows (F-1, D-34 ¶3). The optimistic `stands` hook now treats a derivation a pending render effect reads as part of the hold (scheduler `blockedBy`), as 075bcaf's gate did: over a held flight it stays linked as a stale reader of the hold and is still served the guess, so a <For> keeps showing it (#4525) while the hold keeps its frame; over a flight no transaction holds (a `Loading on` fallback) it reads the derive plainly. A flat memo over every row may keep waiting with the old answer instead of showing the guess (F-2), as #4536's shared-binding test allows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2
🦋 Changeset detectedLatest commit: dce0383 The changes in this PR will be included in the next version bump. This PR includes changesets to release 15 packages
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 |
Size (brotli, eager entry chunk)
|
Coverage Report for CI Build 41293404856Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Coverage remained the same at 78.134%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
Merging this PR will degrade performance by 6.96%2 warnings
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing 
Footnotes
|
… minified) A render effect is read before the gate, so `held` only walks a derivation's subscribers for a pending render effect. Same behaviour. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015hPxMkC3jg3Uivh65gvaf2
…r pass - `held` walks pending derivations transitively (memo -> memo -> binding, mapArray -> memo -> binding) to a pending render effect, as scheduler `blockedBy` judges the frame's hold (F-1). - A reader this pass linked as a stale reader of the hold keeps the guess on its other reads of the family instead of falling to the ordinary pending read: a flat memo over every row now shows `open: [#3][#4]` (D-34 ¶3: however the reads are grouped). The "either outcome" assertion is gone. - The judgment is cached per reader per pass (stamped with `clock`), so a reader's key reads no longer re-walk its subscribers each time (4000 keys x 400 subs guess flush back to ~next). - Pins: two-hop, three-hop and mapArray->memo chains. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWNSSgtemsSYsaX2hXE
Drop the per-pass Map cache for a single-slot one (last reader, the pass's `clock`, its verdict; 2 once this pass linked it): a reader's key reads come in one run, so one slot keeps them from re-walking its subscribers. `held` is a plain early-return recursive walk again; the freshness check is computed once and shared by the linked and unlinked branches. Behaviour, tests and the 4000 keys x 400 subs guess flush unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWNSSgtemsSYsaX2hXE
Member
Author
|
CodSpeed's flagged The relevant perf check is the guess flush at 4000 keys × 400 subscribers (local vitest on source): next 63–65 ms, this head 56–58 ms with user-effect subscribers, and 67–83 ms vs 67–77 ms with render effects. Generated by Claude Code |
…#4561) A diamond graph of pending memos made held() exponential when no pending render effect was reachable. Each derivation is now visited once per walk. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0117BoWNSSgtemsSYsaX2hXE
ryansolid
marked this pull request as ready for review
November 1, 2026 14:44
This was referenced Nov 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4561.
Before: when a memo sits between a keyed list and its split binding, an optimistic guess made while a new question is in flight tore the frame. The filter binding showed
closedwhile the rows still showed the guessedopenlist (closed: [#3][#4]). This happened with and withouton, and underonthe fallback was dropped too. That breaks F-1 (whole frame) and D-34 ¶3 (a guess over a question in flight doesn't answer it).After: the frame stays whole. At the guess the screen shows
open: [#3][#4](the old input plus the guess), orloadingunderon(D-14). After the answer it showsclosed: [#2]. No frame ever pairsclosedwith the guessed rows.The memo was held by the transaction that commits the new question, but its guess re-run ran on mainline inside that transaction's flush. It was served the guess and stopped waiting on the pending derive, so nothing blocked the commit. 5bcd2cb's derivation gate (075bcaf in #4558's history) covered this case, but later commits in #4558 narrowed it to render effects only, so a memo hop slipped through.
How: the
standshook instore/optimistic.tsbrings that gate back asheld(c), which matches a render effect or a derivation read by a pending render effect (the readers in scheduler.tsblockedBy's hold). A held render effect, or any held reader when no transaction owns the flight, still does a plain read of the derive (theLoading onpath). A held derivation under a transaction is linked to the derive and registered as a stale reader of that transaction (staleReader), so it keeps blocking the commit, still gets the guess like lane work (the<For>behaviour from #4525 / D-35 is unchanged), and re-derives when the transaction lands. Everything sits behind the optimistic engine hook, so core, hello world and plaincreateStoreare unchanged (0 B). The new testoptimistic-guess-memo-binding-4561.test.tscovers memo,mapArrayand<For>-style shapes, with and withouton.One residue: with a flat memo over every row and no
on, the guess frame keeps the old answer (open: [#1][#3][#4]) instead of showing the guess. The frame is still whole (F-2, and the existing #4536 shared-effect test already allows it), but D-34 ¶3's "old input plus the guess" isn't met for that one shape. The test accepts either at that frame.Changeset:
patch.Generated by Claude Code