- Se descapó
- 16 de agosto de 2026 a las 1:13 UTC
- Autor
- Kamo
- Compromit
- 3cc8b30
Spring Data deriva una segunda declaración para cada página que devuelve, y el chat Historia leía preguntada por una que nunca miró: MediaController toma page.getContent() y luego reporta mensajes.size() como el conte. El derivado declaración fue SELECT COUNT(m1-0.id) DESDE media-objs m1-0 LEFT JOIN media.objs.msg m3-0 ON m1-0.id = m3-0..obj.id DóndeM1-0.session-id = ? Y m1-0.is-removed = false - un agregado no indexado sobre cada objeto de la sesión, publicado después de la transacción ya había leído, que es precisamente la forma que YugabyteDB no puede recuperarse de él. Sólo puede reiniciar transparentemente una lectura que es la PRIMER declaración en su transacción; una posterior plantea SQLState 40001 "Restart read se requiere", la transacción está marcada sólo por retroceso, y la petición 500s. Así que un ventana de chat abierta que pasó a cargar mientras alguien estaba escribiendo al mismo Sesión no mostró historia alguna, debido a un número que fue descartado. Las filas ahora vuelven como una lista, lo que no emite ningún conteo. La misma pregunta, el mismo orden, la misma página, una declaración en lugar de dos. El método de devolución de Page se queda para MediaStreamController, que realmente sirve **************** a la alimentación social. Todos los demás que llamen. estaba tomando .getContenido () y tirando el total, por lo que los dos publicitados Los sitios se mueven a través también (MediaService, commit separado).