fix(signals): the store's descriptor trap subscribes to the key's presence node - #3530
Conversation
…sence node Object.getOwnPropertyDescriptor read no node: a render effect inspecting a key through it never re-ran for an optimistic add or delete, and an isPending() probe over it witnessed nothing (structural oracle, 2026-09-17 — three cells pinned as violations in #3523). The trap now has `in`'s reactive prelude: affects()/isPending() witness, the projection firewall gate for context-free reads, and a tracked read of the presence node (getHasNode, born from the source's presence as `has` births it). The three descriptor cells flip from violation to rule; suite green; the 1184-cell posture matrix unchanged (it has no pre-existing reader); +3 B brotli on the +createStore scenario. Co-authored-by: Claude via Cursor <noreply@cursor.com>
🦋 Changeset detectedLatest commit: 765a656 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 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 |
Coverage Report for CI Build 35310385914Coverage remained the same at 71.304%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
Merging this PR will degrade performance by 16.52%
|
| Benchmark | BASE |
HEAD |
Efficiency | |
|---|---|---|---|---|
| ❌ | readAllowed |
26.3 µs | 31.5 µs | -16.52% |
Tip
Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.
Comparing fix/store-descriptor-trap (765a656) with next (e1e9f8c)2
Footnotes
-
3 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. ↩
-
No successful run was found on
next(765a656) during the generation of this report, so e1e9f8c was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩
2 participants
Follow-up to #3523's structural oracle states.
Object.getOwnPropertyDescriptoron a store read no node: a render effect that inspected a key through a descriptor never re-ran for an optimistic add or delete, and anisPending()probe over it witnessed nothing. Three cells were pinned asviolation(...)in #3523; this flips them to rules.The trap now has
in's reactive prelude —affects()/isPending()witness, the projection firewall gate for context-free reads, and a tracked read of the presence node (getHasNode, born from the source's presence ashasbirths it). The value it reports is unchanged (visibleDescriptor).rule(...)next(no pre-existing reader kind there)origin/next+createStore; cap ratchetedLeft pinned:
latest()over a held add sees the parked value but not the parked structure (three channels) — a separatelatest()tunnel for presence/key-set nodes.Made with Cursor