solidjs / solid / 36627338981

76%

main: 89%

push

github

fix(signals): unchanged store key read under an adoption hold does not hold the reader (#3707)

Confirming one optimistic move while another was still pending held a
later, independent `drag` write until the second move settled. The
derived store adopted the authoritative array under the still-open
transaction, and the adoption-hold arm of `readSource` entered every
deriving read of that container into the transaction, whichever key it
read.

The adoption hold is now key-scoped like the fold hold (#3688). The
keys an adoption changed against the held view are recorded once per
adoption: own on both backings, never an accessor, same enumerability,
and the store's slot equality, so a re-ingested row counts as the same
logical slot. A get/has/descriptor read of any other key is served the
backing with no hold entry. Keyless reads (`ownKeys`, `$TRACK`,
`deep()`), chained backings, optimistic families and a swapped or
non-plain prototype keep the whole-container hold.

The record is anchored to the adopted object rather than the live
backing, so a mainline setter write during the hold is not attributed
to the adoption and is not held with the adopting transaction. The
record is also consulted on the born-holding path in `getNode` and
before the context-free / children-forbidden arm of `readSource`.

Size: +130..+143 B brotli across the four store-bearing scenarios,
accepted by the maintainer (Size-Exception on the PR).

A row first read after a held adoption inside a deriving memo still
holds the reader. That case is pinned as an expected failure and
tracked in #3712.

Fixes #3706

Co-authored-by: Brenley Dueck <brenleydueck@gmail.com>
Co-authored-by: Claude via Cursor <noreply@cursor.com>

625 of 912 branches covered (68.53%)

Branch coverage included in aggregate %.

936 of 1186 relevant lines covered (78.92%)

27.21 hits per line