solid

Closes #2823 Summary After resizes an array store, previously tracked per-key nodes are never synced against the new value: an effect tracking a removed index stays frozen on the deleted row forever, untracked reads of that index keep returning the deleted row while disagrees, and checks go stale in both directions — a tracked stays after a shrink, a tracked stays after growth. The value-read and growth- symptoms are 1.x → 2.0 regressions. Repro: https://stackblitz.com/edit/solidjs-templates-3dnfxm8y?file=src%2FApp.tsx Root cause The array merge loops in / only write nodes for indices present in the incoming array, then swap . Every other existing node keeps serving its cached value to all reads — tracked and untracked alike, since reads are served from the node whenever one exists — and the array path never writes nodes at all. Two recent fixes each covered an adjacent path and stopped short of this one: #2795 notifies / subscribers (so `reconcile()syncArrayNodeMembershipapplyStateFastapplyStateSlowundefinedhaskey in nextkey in next"1e3""1.5""4294967295"Object.keystests/store/reconcile.test.tsundefinedlengthreconcile([])infalsetrueapplyStateSlowsolid-js@2.0.0-beta.15in2 in listsetPropertyindelete$HASin` reads stay correct; only the subscription goes stale), which is presumably why it went unnoticed since 1.4. This PR makes shrink notification consistent in both directions rather than reproducing that asymmetry one layer down — happy to split that behavior out if parity-exact is preferred. 1.x demonstration: https://playground.solidjs.com/anonymous/03e39514-2569-4143-86d5-b471ada54a09 Full disclosure: I wrote this with the help of an AI assistant (Claude Fable 5) and reviewed every line before pushing. All new tests were written first and confirmed failing on the unfixed code, and the bugs and fixes were both verified against the published beta.15 npm package, not just this repo.

Describe the bug When merges a shorter array into an array store, the per-index nodes for the removed indices are never signaled: 1. An effect (or rendered binding) tracking a removed index ( with ) never re-runs — it stays frozen on the removed row forever, while already reports the shorter length. 2. Because the stale node still exists, even untracked reads of keep returning the removed item — the store proxy contradicts its own . 3. nodes are equally stale, in both directions: a tracked stays after the shrink removes index 2 — and a tracked stays forever after grows the array past index 5 (the merge loops never touch at all). 4. This covers keyed trailing removal, non-keyed arrays, and alike. This is a 2.0 regression for the shrink case: Solid 1.x notifies removed indices (verified on 1.9.14 — the tracking effect re-runs with , and untracked reads agree with , in all three shapes above). Per-symptom 1.x classification (all verified on 1.9.14): the stale value reads (symptoms 1–2) and the growth-direction staleness are 2.0 regressions — 1.x notifies both. The shrink-direction staleness is the one part 1.x shares: a tracked is not notified there either, because its length-truncation branch predates tracking and notifies value nodes only ( and index adds notify correctly). 1.x's version is much milder, though — with no stale node to serve reads, a fresh still returns there, whereas 2.0 serves the stale to every read. Runnable 1.x demonstration (tracked heals, tracked freezes, fresh read contradicts it): https://playground.solidjs.com/anonymous/03e39514-2569-4143-86d5-b471ada54a09 Related to but distinct from two fixed issues: #2773 (fixed in 54b2175c) covered 's / subscribers on trailing removal — so `store.length = n$DELETEDreconcile()lengthAda, Grace, AlanAlan (#3)2 in list: true · Object.keys: [0,1,2]refetch → server now returns only AdaAlan (#3)2 in listtrueObject.keys$TRACK0undefinedhasfalsesetPropertyfor (let i = state.length; i < len; i++) nodes[i].$()nextbad66625list[2]2 in listAlan (#3)trueconsole.log(list[2]){"id":3,"name":"Alan"}2 in listtruelist.length1Object.keys(list)["0"]2 in listfalsepackages/solid-signals/src/store/reconcile.tsapplyStateFastapplyStateSlownext.length[next.length, prevLength)lengthnotifySelftarget[STORE_VALUE]nextlengthhasSTORE_HAS5 in listfalsereconcile()list[5]` reads correctly). Both directions are the same defect — reconcile's array path doesn't maintain per-key nodes against the new value.

Describe the bug Nothing is logged for DEV if we read non resolved async signal in the render part of the component we will get the dev warning Your Example Website or App https://s.olid.uk/id/UFHRJ0VYR2WaBO1FQscBJQ Steps to Reproduce the Bug or Issue playground Expected behavior It is expected that dev warning will be consistent for async signal read that is not in a Loading boundary even though Errored does not propagate the not ready error to the Loading/Suspense boundary it will also have the delay in rendering that is explained by the warning. Screenshots or Videos _No response_ Platform . Additional context _No response_