Optimistic guess tears when the question's transaction is parked on another async read
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 8/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- javascript, typescript
- Área
- frontend
Línea de trabajo
The payload names no source files, so start from the linked issues: read #4536 for the setup and #4525 for how an answer re-bases the optimistic guess, then check the in-progress fix in #4558. Reproduce by adding a second async memo on filter that resolves after the issues query. Done means the frame stays whole in both outcomes the issue allows: the guess holds until the whole transaction commits, or the new question and its answer commit together.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Follow-up to #4536, found while fixing it in #4558. It reproduces on next too.
Repro: take #4536's setup, where one render effect reads the filter question and the keyed list. Add a second async memo on filter that answers after the issues query answers. Make the optimistic guess, then let the issues answer land while that second memo is still in flight.
Observed: open: [#2] | O-open commits and stays on screen until the other flight lands. The filter shows the old question beside the new answer's rows.
Expected: the frame stays whole. Either the guess stays until the whole transaction commits, or the new question and its answer land together (F-1, D-34 ¶3).
Cause (from #4558): when the answer re-bases the guess (#4525), the lane gets the question's transaction. If that transaction is still parked on another async read, the guess is dropped before the transaction commits.
- Lenguaje dominante
- TypeScript
- Estrellas
- 36.2k
- Forks
- 1.1k
- Merge medio
- 11 h 28 min
- PR fusionados (30 d)
- 461
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 4/5 3-5 días Aptitud para principiantes 15/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 14/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 28/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
Todos los issues de solidjs/solid
Issues similares
-
guards: accept readonly arrays (and other array-likes) in isEmpty / hasElements / safeLengthAbiertoenhancement tech debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
danielmiessler/LifeOS#2533 ·
Los mantenedores suelen responder en 9 días
-
auto:producer auto:uiux
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
fritzprix/libr-agent#2447 ·
Los mantenedores suelen responder en 1 día
-
bug low priority
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100