Ho riscontrato un problema intermittente mentre modificavo un post esistente nella mia istanza self-hosted di Discourse il 21 ottobre 2026. Il compositore si è bloccato nello stato Salvataggio e non sono riuscito a tornare all’editor per recuperare del testo dettato.
Da allora ho esaminato i log di accesso di Caddy e nginx e la cronologia delle revisioni dei post di Discourse.
Ambiente
-
Client: iPhone 16 Pro, PWA Safari Home Screen
-
iOS: 27.0.1
-
Discourse:
2026.10.0-latest +406 commits, come mostrato nella dashboard di amministrazione in quel giorno (disponibili 162 modifiche più recenti) -
Hosting: self-hosted, archivio privato di studio
-
Reverse proxy: Caddy v2.11.4, che fornisce HTTP/3 su QUIC
-
Backend: nginx di Discourse dietro Caddy tramite socket Unix
-
Rete: inizialmente Wi-Fi universitario, seguito da rete cellulare EE
Cosa è successo
Stavo modificando un post contenente un’immagine di una slide di una lezione di fisica.
Ho dettato ulteriori note matematiche, inclusi frazioni, sotto l’immagine e poi ho premuto rapidamente Salva Modifica.
La barra orizzontale blu Salvataggio rimasta visibile in basso sullo schermo non si è completata.
Ho provato a toccare la barra Salvataggio, ma questo non ha riaperto il compositore. Di conseguenza, non sono riuscito a selezionare o copiare il testo non salvato altrove.
Ho aspettato più a lungo del solito.
Solo dopo che l’operazione di Salvataggio era già bloccata ho disabilitato manualmente il Wi-Fi, sperando che il passaggio alla rete cellulare permettesse al richiedimento di completarsi.
L’interfaccia non si è ripresa immediatamente. Ho anche riscontrato buffering quando cercavo di navigare utilizzando il logo del sito.
Quando sono potuto tornare a modificare il post, le frazioni dettate mancavano.
Indagine lato server
L’orario rilevante era approssimativamente le 12:20 BST del 21 ottobre 2026.
I miei log di Caddy mostrano:
| Ora (BST) | Richiesta | Risultato |
|---|---|---|
| 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 |
Stato Caddy 0 |
| 12:20:55 | PUT /posts/70695 |
200 |
Il PUT non riuscito ha utilizzato HTTP/3. Caddy ha registrato una durata di circa 110 ms, mentre nginx ha registrato una risposta HTTP 400 senza esecuzione del controller di aggiornamento del post di Discourse.
Numerose altre richieste provenienti dalla connessione cellulare hanno ricevuto lo stato Caddy 0 approssimativamente nello stesso momento.
Caddy stesso non è stato riavviato. Docker riporta zero riavvii dal 15 ottobre e i log operativi non contengono eventi corrispondenti di reload o arresto.
Recupero bozze
C’erano richieste di salvataggio bozza riuscite immediatamente prima dell’incidente.
Tuttavia, ricordo i contenuti precedenti come l’immagine della slide senza il testo aggiuntivo dettato. Ho inserito le frazioni successivamente e ho premuto Salva Modifica poco dopo.
Pertanto, non posso stabilire che la dettatura mancante fosse inclusa in uno dei due autosave riusciti.
Quando ho successivamente ispezionato le revisioni del post, la revisione riuscita alle 12:20:55 conteneva l’immagine ma non le frazioni dettate.
Ho anche controllato i record attuali delle bozze, ma né la chiave della bozza del vecchio argomento né quella nuova avevano una bozza rimanente al momento dell’ispezione.
Comportamento atteso
Se una richiesta di modifica si blocca o viene interrotta, mi aspetterei che il compositore preservasse i suoi contenuti non salvati e fornisse un modo per riprovare, annullare o tornare alla modifica.
In particolare, l’interfaccia dovrebbe idealmente non rendere il testo non salvato inaccessibile indefinitamente mostrando Salvataggio.
Comportamento attuale
Il compositore è rimasto inaccessibile, toccare la barra Salvataggio non l’ha riaperto e il testo dettato non era più disponibile quando la modifica è ripresa.
Domande
-
Ci si aspetta che il compositore rimanga inaccessibile indefinitamente mentre una richiesta di modifica è pendente?
-
Esiste un timeout o un meccanismo di recupero destinato a ripristinare la modifica quando una richiesta di rete viene interrotta?
-
Un’operazione di Salva Modifica interrotta dovrebbe preservare il testo in memoria o i contenuti della bozza anche se la richiesta non raggiunge mai il controller di aggiornamento del post di Rails?
-
Sarebbe utile qualche logging o strumentazione client-side particolare se questo succedesse di nuovo su iOS?
Apprezzo che il cambio di rete possa spiegare le eventuali cancellazioni delle richieste. Tuttavia, l’interfaccia di Salvataggio si era già bloccata prima che cambiassi manualmente rete.
Non ho stabilito se il ritardo iniziale provenisse dal JavaScript di Discourse, dalla rete iOS/WebKit o dalla connessione universitaria.
Discussioni correlate
Ho una discussione esistente su MPTCP / continuità della connessione iOS, dove ho descritto questo stesso incidente dal punto di vista del trasporto.
Ho anche precedentemente segnalato che i post modificati occasionalmente restano obsoleti in DiscourseHub su iOS. In quel problema separato, le modifiche avevano raggiunto con successo il server, ma il post già renderizzato non si aggiornava fino ad un refresh. Un altro utente ha riferito di aver notato anche lui quel comportamento.
Non so se i due problemi condividono una causa. L’incidente attuale è diverso perché la richiesta iniziale di modifica del post non è stata elaborata con successo.
Ho anche trovato due segnalazioni precedenti che coinvolgono un compositore bloccato in Salvataggio:
Entrambi avevano cause identificate diverse e non do per scontato che spieghino questo incidente.
Ho allegato un ZIP discourse_ios_save_evidence_2026-10-21_domain_redacted.zip (6,3 KB) contenente estratti diagnostici selezionati e censurati di Caddy/nginx, informazioni sulle revisioni e la cronologia descritta sopra.
Sarei grato per qualsiasi consiglio su come il compositore sia previsto che si riprenda da una richiesta rallentata, in particolare quando le modifiche non salvate non possono essere copiate prima di un’interruzione di rete.