- Se descapó
- 14 de agosto de 2026 a las 2:10 UTC
- Autor
- kamo
- Compromit
- a948e2c
Tres cosas se ralentizaban los mensajes antes de que se llevara a cabo un solo mensaje. Cada llamada de correo electrónico hizo un viaje de ida y vuelta a /api/generate-otk primero y envió el resultado como X-OTK. Ninguna ruta de este lado ha leído nunca esa cabecera: el proxy mentas su propia OTK de un solo uso de la sesión de la persona que llamó en buildForwardHeaders, que es lo que realmente autentica el salto a EmailService. Así que cada petición fue realmente dos, la primera en serie frente a la segunda, más dos operaciones Redis A través de 58 sitios de llamadas en 18 archivos, cada uno con su propia copia del ayudante. Uno el sitio de llamadas ya había resuelto esto y lo dijo en un comentario; el resto son ahora de acuerdo con ella. El cruce de origen se encuentra en handoff en page.tsx está intacto, como que OTK viaja a otro origen y se valida allí. El árbol de carpetas era lo último en la página que se le pedía, por una razón que no tenía nada que ver con las carpetas. FolderSidebar es un niño de MessageBrowser, que deja un esqueleto de botas en vez de sus hijos hasta el proveedor y el Los buzones de correos accesibles de los miembros han respondido a dos viajes de ida y vuelta en serie. El lista de mensajes nunca esperó, porque su captura vive en un efecto y los efectos corren lo que sea que el componente regrese. Carpetas solas se sentaron detrás de la puerta. Un efecto ahora comienza esa petición en el montaje, y la barra lateral se une en lugar de abrir un segundo. "Qué buzones puede abrirse este miembro" se preguntó dos veces en un montaje, por usEmailDisponibilidad y por MessageBrowser, cada uno haciendo EmailService caminar el buzón de correo, departamento, puesto de trabajo y subvenciones de supervisión. Las respuestas están ahora compartido durante treinta segundos y dejado caer por cada llamada que pueda cambiarlos. Junto a eso, /messages recuerda el árbol de carpetas y la primera página la última mostrado, por tabique, y pintelos mientras las versiones en vivo se cargan. Los datos cachés sólo un primer marco. Cada lectura sigue siendo seguido por una petición real y sustituyó por ella, por lo que una entrada rancia cuesta un parpadeo, nunca una respuesta equivocada.