[2.0 / next] laneRead's D-28 verdict-seat reset compares verdict lanes by identity; a merged transaction's lane reads as another hold's
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 43/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- javascript, typescript
- Área
- frontend, performance
Línea de trabajo
Start by reading the D-28 reset and reader-seat logic referenced in #4275, #4284, and #4395, then reproduce the reported case in packages/web/test/async-gen with seed 3289, case #43. Check how the verdict-seat comparison handles transactions merged through _into; done when the merged hold keeps the reader seated and reads the lane value, with the async-gen regression case passing.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
laneRead's D-28 reset (#4275, #4284) — "a verdict lane's seat does not carry a leaf into another lane" — compares verdict lanes by object identity: passLane !== l && passLane._parent._verdict === passLane. After a transaction merge (A._into = B), A's verdict lane and B's verdict lane are two objects for one hold. A render effect seated as B's verdict reader (its latest() of a node B holds routed it to verdictLane(txOf(el)), resolved) then reads a derivation that still sits in A._verdict (its _x._transaction was stamped before the merge): the reset fires as if the leaf had crossed into another hold's lane, passLane is cleared, and the leaf is served the staging through the L7' arm (c held by the flush's transaction) instead of staying seated and reading the lane's value.
The hold is the same; only the lane object differs. The leaf leaves its own hold's verdict seat for the rest of the pass.
Reproduction
async-gen seed 3289 case #43 (packages/web/test/async-gen):
const sc = fc.sample(scenarioArb(), { seed: 3289, numRuns: 44 })[43];
await runScenario(sc);
[s0=1 s1=2 m0=memo(latest(s1) !%4=3) m1=async(latest(s1) !%4=0)]
<span split[s1()]>s0()</span><Show when=m0()><span></span></Show><Loading><span fx[latest(s1),m1()]>m0()</span></Loading>
:: f A(s1=1) s0=1 s1=0 s0=3 s0=3 m S1 A(s0=3)
scenario JSON
{"signals":[1,2],"memos":[{"async":false,"deps":[{"src":{"k":"s","i":1},"how":"latest"}],"poison":3},{"async":true,"deps":[{"src":{"k":"s","i":1},"how":"latest"}],"poison":0}],"tree":{"t":"group","kids":[{"t":"leaf","text":[{"how":"plain","src":{"k":"s","i":0}}],"attrs":[{"how":"plain","src":{"k":"s","i":1}}],"grouped":false},{"t":"show","when":{"how":"plain","src":{"k":"m","i":0}},"child":{"t":"leaf","text":[],"attrs":[],"grouped":true},"fallback":false},{"t":"loading","child":{"t":"leaf","text":[{"how":"plain","src":{"k":"m","i":0}}],"attrs":[{"how":"latest","src":{"k":"s","i":1}},{"how":"plain","src":{"k":"m","i":1}}],"grouped":true}}]},"steps":[{"t":"flush"},{"t":"action","s":1,"v":1},{"t":"write","s":0,"v":1},{"t":"write","s":1,"v":0},{"t":"write","s":0,"v":3},{"t":"write","s":0,"v":3},{"t":"micro"},{"t":"settle","pick":1},{"t":"action","s":0,"v":3}]}
The fx[latest(s1), m1()] render effect reads latest(s1) (held → seated as the hold's verdict reader), then m1 — a verdict-lane derivation whose lane's _parent has been merged (resolveTx(l._parent) !== l._parent) into the very hold the leaf is seated for. Observed: passLane reset, m1's staging served (L7'). The reader-seat table (#4395, row V6/L6) compares holds, not lane objects: no leave, the lane's value.
Found by the S1 reader-seat differential: class V6 expected Lv, got P — slot (V posture; s u d ip vlane parentMerged shown · cU cH cOtherTx t1 w2 vseat oldNoLane flushTx flushNotElTx) plus the downstream verdict seat at the pass's end (old none, new seated), 1 case in the 1500-case regression gate, none in the signals or web suites. The case's screens are all [ROOT-E] (the m0 poison), so nothing visible differs here; the mechanism is wrong independent of the screen.
Why it is a bug
- D-28 / #4284: the leaf leaves the verdict seat for a lane that is not that hold's. A merged transaction's verdict lane is that hold's.
- Lane identity surviving a merge is a #3905-adjacent artifact (
verdictLane(t)is per transaction object; nodes stamped before the merge keep the old lane). Every other seat comparison in the engine resolves (txOf,resolveTx); this one does not.
Intended fix
The reader-seat rebuild S1 (#4395) decides the leave from the seat's hold (resolveTx(vhold) !== resolveTx(l._parent)), which fixes this by construction. Until the swap lands, the shadow carries this as a known class (shadowKnown, this issue). #3905 (transaction merging) is the structural fix for lanes keeping pre-merge identities and stays out of scope here.
- Lenguaje dominante
- TypeScript
- Estrellas
- 36.2k
- Forks
- 1.1k
- Merge medio
- 11 h 48 min
- PR fusionados (30 d)
- 441
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de solidjs/solid
-
Dificultad 3/5 1-2 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 58/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
Los mantenedores suelen responder en 1 día
Todos los issues de solidjs/solid
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
components-web-app/docs#311 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
NEARBuilders/everything-dev#678 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 1-3 horas Aptitud para principiantes 90/100
formbricks/formbricks#9881 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día