Repository navigation
Conversation
An async memo over isPending(x) showed 'pending: true' beside an isPending(x) binding still false: the parent landing at the lane's seam voided the binding's lane run while the memo's run showed. The voided runs now show with the lane's (F-6, F-1); the landing's re-derivation follows next round. The second order from the issue (a landing flush's own run shown beside held runs parked with a re-derivation, F-1/F-7) is pinned it.fails. Co-authored-by: tembo[bot] <208362400+tembo-io[bot]@users.noreply.github.com>
Five rows, +111 B minified each from #4677 and +7 B from #4682 (not re-recorded yet): signals + isPending/latest, app hydrating + every store family, the live page (a frozen floor, Size-Exception in the PR body), the compiled live page and live + router. Measured locally over next @ 5208944 with the in-repo compiler build; caps are measured brotli + 10 B. Co-authored-by: tembo[bot] <208362400+tembo-io[bot]@users.noreply.github.com>
🦋 Changeset detectedLatest commit: 1e4d374 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)
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 |
Coverage Report for CI Build 41982111029Coverage remained the same at 78.249%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
Merging this PR will regress 1 benchmark2 warnings
Warning Please fix the performance issues or acknowledge them on CodSpeed. Performance Changes
Tip Investigate this regression by commenting Comparing 
Footnotes
|
…plit Co-authored-by: Ryan <ryansolid@gmail.com>
Summary
Fixes #4677 (issue's repro): an async memo that reads
isPending(id)publishedpending: truewhile anisPending(id)binding beside it still showedfalse.Checked against
docs/RULES-FUNDAMENTALS.md/RULES-DERIVED.md. The badge memo is a verdict reader (D-25), so its async opens a lane (F-6). When details landed first, the parent (the write toid) waited on the lane's flight, so the lane and the parent landed at the same seam. The landing'srerunsvoided the verdict binding's stashed lane run (the run is for the frame being replaced) while the badge's run from the same lane still showed. The lane split, breaking F-6 (its readers show its answer together) and F-1.Ruled screen (reading A, confirmed with the maintainer): the lane reveals whole, then everything moves at the badge's re-derived landing.
Fix (
lanes.tslaneSeam, about 10 lines, pay-for-use lane engine only). When a revealing lane has other runs that show, the runs its parent's landing would void are restored ahead of the lane's runs, so they show together. The landing's re-derivation still follows next round. The guard (more lane runs than restored ones) keeps a lane holding only voided runs (e.g. a first load) unchanged.Still open, pinned
it.fails. In the second order (the lane lands first, then details), the landing flush's own run (details: Item 1) shows besideid: 0, while the held runs park with the badge's re-derivation (U-5): an F-1/F-7 tear the issue doesn't mention. Deferring the flush's own runs with the held runs breaks #4398's grouping parity (latest-first-one-pass-4402.test.ts), where the held runs are only verdict readers. Telling the two apart would need new run-queue bookkeeping, so that's left for a follow-up.Public API changes
None.
Size
+111 B minified on the five rows that carry the lane engine; every floor and every non-lane scenario is unchanged. The second commit re-records them in this PR (not in a batch), together with #4682's +7 B, which hadn't been re-recorded and had already put the live page 50 B over its cap:
Measured locally (compiler built from source, then
pnpm build, as insize.yml) overnext@ 5208944, with and without the fix. CI's numbers may differ by tens of brotli bytes.Size-Exception: #4677 lane-split fix (+111 B minified on lane pages) plus #4682's unrecorded +7 B, re-recorded on the live-page floor at the maintainer's request.
How did you test this change?
packages/signals/tests/ispending-async-derivation-4677.test.ts: the baseline order, the issue's order (fixed; it failed before the change at exactly the split frame), and the second order pinnedit.failsat its ruled screen.@solidjs/compilerbuild, thenpnpm build: 30/30 tasks..nvmrc). On Node 22 one server-function test fails because Node 22'sRequestaccepts a non-AbortSignalsignal; that's unrelated to this change.node scripts/size/size.mjs: the gate passes.check-floor-caps.mjspasses with theSize-Exceptionline above.