Encontré un problema intermitente mientras editaba una publicación existente en mi instancia autoalojada de Discourse el 21 de octubre de 2026. El compositor se quedó atascado en su estado Guardando y no pude volver al editor para recuperar parte del texto dictado.
Desde entonces, he examinado los registros de acceso de Caddy y nginx y el historial de revisiones de publicaciones de Discourse.
Entorno
-
Cliente: iPhone 16 Pro, PWA de Safari en la pantalla de inicio
-
iOS: 27.0.1
-
Discourse:
2026.10.0-latest +406 commits, como se muestra en el panel de administración más tarde ese día (había 162 cambios nuevos disponibles) -
Alojamiento: autoalojado, archivo privado de estudio
-
Proxy inverso: Caddy v2.11.4, proporcionando HTTP/3 sobre QUIC
-
Backend: nginx de Discourse detrás de Caddy usando un socket Unix
-
Red: inicialmente Wi-Fi universitario, seguido de red celular de EE
Qué sucedió
Estaba editando una publicación que contenía una imagen de una diapositiva de una clase de física.
Dicté notas matemáticas adicionales, incluyendo fracciones, debajo de la imagen y luego presioné rápidamente Guardar edición.
La barra horizontal azul de Guardando permaneció visible en la parte inferior de la pantalla y no se completó.
Intenté tocar la barra de Guardando, pero esto no reabrió el compositor. Como resultado, no pude seleccionar ni copiar el texto no guardado en otro lugar.
Esperé más tiempo de lo habitual.
Solo después de que la operación de Guardar ya estuviera atascada desactivé manualmente el Wi-Fi, con la esperanza de que cambiar a la red celular permitiera completar la solicitud.
La interfaz no se recuperó inmediatamente. También experimenté buffering al intentar navegar usando el logo del sitio.
Cuando pude editar la publicación nuevamente, las fracciones dictadas estaban ausentes.
Investigación del lado del servidor
El momento relevante fue aproximadamente 12:20 BST del 21 de octubre de 2026.
Mis registros de Caddy muestran:
| Hora (BST) | Solicitud | Resultado |
|---|---|---|
| 12:19:39 | POST /drafts.json |
200 |
| 12:19:40 | POST /uploads.json |
200 |
| 12:19:44 | POST /drafts.json |
200 |
| 12:20:08 | PUT /posts/70695 |
Estado de Caddy 0 |
| 12:20:55 | PUT /posts/70695 |
200 |
La solicitud PUT fallida usó HTTP/3. Caddy registró una duración de aproximadamente 110 ms, mientras que nginx registró una respuesta HTTP 400 sin ejecución del controlador de actualización de publicaciones de Discourse.
Numerosas otras solicitudes originadas desde la conexión celular también recibieron estado de Caddy 0 aproximadamente al mismo tiempo.
Caddy mismo no se reinició. Docker informa cero reinicios desde el 15 de octubre, y los registros operativos no contienen ningún evento correspondiente de recarga o apagado.
Recuperación de borradores
Hubo solicitudes exitosas de guardado de borradores inmediatamente antes del incidente.
Sin embargo, recuerdo los contenidos anteriores como la imagen de la diapositiva sin el texto adicional dictado. Ingresé las fracciones después y presioné Guardar edición poco después.
Por lo tanto, no puedo establecer que la dictadura faltante estuviera incluida en ninguno de los autoguardados exitosos.
Cuando inspeccioné posteriormente las revisiones de la publicación, la revisión exitosa de las 12:20:55 contenía la imagen pero no las fracciones dictadas.
También revisé los registros actuales de borradores, pero ni la clave antigua ni la nueva de borrador del tema tenían un borrador restante en el momento de la inspección.
Comportamiento esperado
Si una solicitud de edición se queda atascada o se interrumpe, esperaría que el compositor preservara sus contenidos no guardados y proporcionara una forma de reintentar, cancelar o volver a editar.
En particular, la interfaz idealmente no debería hacer inaccesible indefinidamente el texto no guardado mientras muestra Guardando.
Comportamiento real
El compositor permaneció inaccesible, tocar la barra de Guardando no la reabrió y el texto dictado ya no estaba disponible cuando se reanudó la edición.
Preguntas
-
¿Se espera que el compositor permanezca inaccesible indefinidamente mientras una solicitud de edición está pendiente?
-
¿Existe un mecanismo de timeout o recuperación destinado a restaurar la edición cuando una solicitud de red se interrumpe?
-
¿Debería una operación de Guardar edición interrumpida preservar el texto en memoria o los contenidos del borrador incluso si la solicitud nunca llega al controlador de actualización de publicaciones de Rails?
-
¿Sería útil algún registro o instrumentación específica del lado del cliente si esto sucede nuevamente en iOS?
Aprecio que el cambio de red pueda explicar las cancelaciones eventuales de la solicitud. Sin embargo, la interfaz de Guardando ya se había quedado atascada antes de que yo cambiara manualmente de redes.
No he establecido si el retraso inicial se originó en JavaScript de Discourse, en la red de iOS/WebKit o en la conexión universitaria.
Discusiones relacionadas
Tengo una discusión existente sobre MPTCP / continuidad de conexión de iOS, donde describí este mismo incidente desde la perspectiva del transporte.
También reporté anteriormente que publicaciones editadas a veces permanecen obsoletas en DiscourseHub en iOS. En ese problema separado, las ediciones habían llegado exitosamente al servidor, pero la publicación ya renderizada no se actualizó hasta hacer un refresco. Otro usuario informó haber notado ese comportamiento también.
No sé si los dos problemas comparten una causa. El incidente actual es diferente porque la solicitud inicial de edición de la publicación no se procesó con éxito.
También encontré dos informes anteriores involucrando un compositor atascado en Guardando:
-
Después de editar, la barra “Guardando” se queda atascada (2023)
-
Compositor atascado en estado “Guardando” cuando el tema requiere moderación (2026)
Ambos tenían causas identificadas diferentes, y no asumo que expliquen este incidente.
He adjuntado un ZIP discourse_ios_save_evidence_2026-10-21_domain_redacted.zip (6.3 KB) que contiene extractos seleccionados y anonimizados de diagnósticos de Caddy/nginx, información de revisiones y la cronología descrita anteriormente.
Agradecería cualquier consejo sobre cómo se supone que debe recuperar el compositor de una solicitud detenida, especialmente cuando los cambios no guardados no pueden copiarse antes de una interrupción de red.