Am 21. Oktober 2026 ist mir bei der Bearbeitung eines bestehenden Beitrags in meiner selbst gehosteten Discourse-Instanz ein intermittierendes Problem aufgefallen. Der Composer blieb im Speichern-Zustand hängen, und ich konnte nicht zum Editor zurückkehren, um einige diktierte Texte zu retten.
Seither habe ich die Access-Logs von Caddy und nginx sowie die Versionshistorie der Beiträge in Discourse überprüft.
Umgebung
-
Client: iPhone 16 Pro, Safari Home Screen PWA
-
iOS: 27.0.1
-
Discourse:
2026.10.0-latest +406 commits, wie am selben Tag später im Admin-Dashboard angezeigt (162 neuere Änderungen verfügbar) -
Hosting: self-hosted, privates Studienarchiv
-
Reverse Proxy: Caddy v2.11.4, bereitstellt HTTP/3 über QUIC
-
Backend: Discourse nginx hinter Caddy über einen Unix-Socket
-
Netzwerk: zunächst UniversitätswLAN, danach EE-Mobilfunk
Was passiert ist
Ich bearbeitete einen Beitrag, der ein Bild einer Physik-Vorlesungsfolie enthielt.
Ich diktierte zusätzliche mathematische Notizen, einschließlich Bruchzahlen, unter dem Bild und drückte dann schnell auf Bearbeitung speichern.
Der blaue horizontale Speichern-Balken blieb unten auf dem Bildschirm sichtbar und wurde nicht abgeschlossen.
Ich versuchte, den Speichern-Balken anzutippen, aber dies öffnete den Composer nicht erneut. Infolgedessen konnte ich den ungespeicherten Text nicht auswählen oder an anderer Stelle kopieren.
Ich wartete länger als üblich.
Erst nachdem die Speicheroperation bereits festgefahren war, deaktivierte ich manuell das WLAN, in der Hoffnung, dass der Wechsel zum Mobilfunknetz die Anfrage abschließen würde.
Die Oberfläche erholte sich nicht sofort. Ich erlebte auch Pufferungen beim Versuch, über das Site-Logo zu navigieren.
Als ich den Beitrag wieder bearbeiten konnte, fehlten die diktierten Bruchzahlen.
Serverseitige Untersuchung
Der relevante Zeitpunkt lag ungefähr bei 12:20 BST am 21. Oktober 2026.
Meine Caddy-Logs zeigen:
| Zeit (BST) | Anfrage | Ergebnis |
|---|---|---|
| 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 |
Caddy Status 0 |
| 12:20:55 | PUT /posts/70695 |
200 |
Die gescheiterte PUT-Anfrage nutzte HTTP/3. Caddy protokollierte eine Dauer von etwa 110 ms, während nginx eine HTTP-400-Antwort ohne Ausführung des Discourse-Post-Update-Controllers protokollierte.
Zahlreiche andere Anfragen aus dem Mobilfunknetz erhielten zur gleichen Zeit ebenfalls den Caddy-Status 0.
Caddy selbst wurde nicht neu gestartet. Docker meldet seit dem 15. Oktober null Neustarts, und die Betriebslogs enthalten kein entsprechendes Reload- oder Shutdown-Ereignis.
Entwurfsrettung
Direkt vor dem Vorfall gab es erfolgreiche Entwurfsspeicheranfragen.
Dennoch erinnere ich mich an den früheren Inhalt als die Folienabbildung ohne den zusätzlichen diktierten Text. Ich gab die Bruchzahlen anschließend ein und drückte kurz darauf auf Bearbeitung speichern.
Daher kann ich nicht feststellen, dass der fehlte Diktattext in einem der erfolgreichen Autosaves enthalten war.
Als ich später die Beitragsversionen inspizierte, enthielt die erfolgreiche Version um 12:20:55 das Bild, aber nicht die diktierten Bruchzahlen.
Ich prüfte auch die aktuellen Entwurfsdatensätze, aber weder der alte noch der neue Topic-Entwurfschlüssel hatte zum Zeitpunkt der Prüfung einen verbleibenden Entwurf.
Erwartetes Verhalten
Wenn eine Bearbeitungsanfrage festfährt oder unterbrochen wird, würde ich erwarten, dass der Composer seine ungespeicherten Inhalte beibehält und eine Möglichkeit bietet, erneut zu versuchen, abzubbrechen oder zur Bearbeitung zurückzukehren.
Insbesondere sollte die Oberfläche idealerweise ungespeicherten Text nicht dauerhaft unzugänglich machen, während sie „Speichern“ anzeigt.
Tatsächliches Verhalten
Der Composer blieb unzugänglich, das Antippen des Speichern-Balkens öffnete ihn nicht erneut, und der diktierte Text stand bei Wiederaufnahme der Bearbeitung nicht mehr zur Verfügung.
Fragen
-
Soll der Composer so lange unzugänglich bleiben, bis eine ausstehende Bearbeitungsanfrage abgeschlossen ist?
-
Gibt es einen Timeout- oder Wiederherstellungsmechanismus, der die Bearbeitung wiederherstellen soll, wenn eine Netzwerkanfrage unterbrochen wird?
-
Sollte eine unterbrochene „Bearbeitung speichern“-Operation den Arbeitsspeicher-Text oder die Entwurfsinhalte beibehalten, selbst wenn die Anfrage den Rails-Post-Update-Controller nie erreicht?
-
Würde eine bestimmte clientseitige Protokollierung oder Instrumentierung nützlich sein, falls dies erneut auf iOS passiert?
Ich schätze, dass die Netzwerkänderung die endgültigen Anfragesabbrüche erklären mag. Allerdings war die Speicher-Oberfläche bereits festgefahren, bevor ich manuell das Netzwerk wechselte.
Ich habe nicht festgestellt, ob die anfängliche Verzögerung in der JavaScript-Implementierung von Discourse, im iOS/WebKit-Netzwerk oder in der Verbindung der Universität ihren Ursprung hatte.
Verwandte Diskussionen
Ich habe eine bestehende MPTCP / iOS-Verbindungsfortsetzung-Diskussion, in der ich diesen gleichen Vorfall aus der Transportperspektive beschrieben habe.
Zuvor habe ich auch gemeldet, dass bearbeitete Beiträge gelegentlich in DiscourseHub auf iOS veraltet bleiben. Bei diesem separaten Problem hatten die Bearbeitungen den Server erfolgreich erreicht, aber der bereits gerenderte Beitrag aktualisierte sich nicht, bis ein Refresh durchgeführt wurde. Ein anderer Benutzer berichtete, dieses Verhalten ebenfalls bemerkt zu haben.
Ich weiß nicht, ob die beiden Probleme eine gemeinsame Ursache haben. Der aktuelle Vorfall unterscheidet sich dadurch, dass die anfängliche Beitragsbearbeitungsanfrage nicht erfolgreich verarbeitet wurde.
Ich fand auch zwei frühere Berichte über einen Composer, der im Speichern-Zustand festhing:
-
Nach dem Bearbeiten bleibt der „Speichern“-Balken hängen (2023)
-
Composer hängt im „Speichern“-Zustand, wenn das Thema Moderation erfordert (2026)
Beide hatten unterschiedlich identifizierte Ursachen, und ich nehme nicht an, dass sie diesen Vorfall erklären.
Ich habe eine ZIP-Datei angehängt discourse_ios_save_evidence_2026-10-21_domain_redacted.zip (6,3 KB), die ausgewählte, redigierte Caddy/nginx-Diagnoseauszüge, Versionsinformationen und die oben beschriebene Chronologie enthält.
Ich wäre für jeden Rat dankbar, wie der Composer von einer stockenden Anfrage aus erholt werden soll, insbesondere wenn ungespeicherte Änderungen vor einer Netzwerkunterbrechung nicht kopiert werden können.