Ich bin auf ein intermittierendes Problem gestoßen, bei dem ein bearbeiteter Beitrag zwar erfolgreich gespeichert wird, der bereits gerenderte Beitrag in DiscourseHub auf dem iOS-Gerät sich aber manchmal veraltet darstellt, bis ich das Thema aktualisiere.
Umgebung
Die Produktionsumgebung ist meine eigene selbst gehostete Discourse-Installation, die ich privat als persönlichen Lernarchiv verwende.
Zum Zeitpunkt der Reproduktion heute:
- Client: DiscourseHub auf dem iPhone
- iOS: 27.0.1
- Produktions-Discourse:
v2026.10.0-latest +112 - Site: selbst gehostet, privates Lernarchiv
- Standard-iOS-Browser: iCab Mobile
Ich habe meinen Standardbrowser auf iCab Mobile geändert, da ein damit zusammenhängendes Problem mit lokalen Downloads vorlag. Diese Reproduktion erfolgte jedoch, während ich die Discourse-Site innerhalb von DiscourseHub nutzte, und nicht nach dem Öffnen eines externen Browsers. Daher halte ich die Wahl des Standardbrowsers derzeit nicht für relevant.
Workflow in der Praxis
Das Thema, in dem ich dies bemerkt habe, enthielt etwa 50 Beiträge, die Folien eines Vortrags darstellten.
Mein üblicher Workflow ist:
- einen Beitrag mit einem Bild einer Vorlesungsfolie erstellen;
- das Thema später nacheinander durchgehen;
- jeden vorhandenen Beitrag bearbeiten;
- unter das bereits gepostete Folienbild einen OCR-Transkript-/Notiztext hinzufügen;
- auf Änderungen speichern drücken und mit der nächsten Folie fortfahren.
Es handelt sich also nicht um synthetische, schnelle Bearbeitungen: Dies ist ein normaler Lernworkflow, bei dem ich schrittweise OCR-Transkripte zu Beiträgen mit Vorlesungsfolienbildern hinzufüge.
Bei den früheren Beiträgen im Thema ersetzte das Drücken auf Änderungen speichern den angezeigten Beitrag sofort durch den neu bearbeiteten Inhalt, wie erwartet.
Später im selben Thema stieß ich auf Fälle, in denen:
- ich den Beitrag bearbeitete und den OCR-Text hinzufügte.
- auf Änderungen speichern drückte.
- die Bearbeitung erfolgreich gespeichert wurde.
- der in DiscourseHub angezeigte Beitrag bei seinem vorherigen Inhalt verblieb.
- das Aktualisieren der Seite die bereits gespeicherte Bearbeitung sofort anzeigte.
Die Bearbeitung selbst scheint also erfolgreich gewesen zu sein. Der veraltete Teil scheint die bereits geladene Client-Darstellung des Beitrags zu sein.
Entwicklungstest
Ich erstellte dann eine völlig saubere Entwicklungsumgebung aus dem aktuellen Upstream-main:
833e1576d47 DEV: Update README.md note on self-hosting (#44320)
Ich generierte ein Thema mit 60 Beiträgen, wobei jeder Beitrag ein Bild enthielt, um die Struktur des Produktionsthemas nachzuahmen.
Ich wiederholte den Workflow dann in Firefox auf Linux und bearbeitete Text in den vorhandenen Bildbeiträgen.
In meinem ersten Test sah ich zunächst eine mögliche veraltete Aktualisierung um Beitrag 19 herum.
Nachdem ich das Experiment jedoch sorgfältiger wiederholt hatte – einschließlich der Erstellung eines neuen 60-Beiträge-Themas und der nacheinander erfolgenden Bearbeitung der Beiträge –, konnte ich das Produktionsverhalten in Firefox/Linux auf dem aktuellen main nicht reproduzieren.
Die Bearbeitungen dort haben den Beitrag sofort nach dem Speichern neu gerendert, auch weit über die erste Gruppe von Beiträgen im Thema hinaus.
Das hat mich weniger davon überzeugt, dass die Themen-Paginierung oder der normale 20-Beiträge-Stream-Chunk die Ursache ist.
Nächster Test
Die Reproduktion in der Produktion erfolgte in DiscourseHub auf iOS, nicht in einer Home-Screen-PWA.
Mein nächster vorgesehener Vergleich ist daher:
- aktuelle Upstream-Discourse-Entwicklungsumgebung;
- dasselbe 60-Beiträge-Bildthema;
- dasselbe iPhone mit iOS 27.0.1;
- zuerst DiscourseHub;
- Safari auf demselben iPhone als Kontrolle;
- optional die Home-Screen-Web-App als weiterer Vergleich;
- die Beiträge nacheinander mit demselben OCR-ähnlichen Workflow bearbeiten.
Derzeit ist mein Entwicklungslaptop über eduroam verbunden, daher ist es nicht einfach, seinen lokalen Entwicklungsserver direkt dem iPhone zugänglich zu machen.
Ist es der richtige nächste Schritt, die Entwicklungsumgebung mit dem aktuellen main auf demselben iPhone in DiscourseHub auszuführen, um das Problem einzugrenzen?
Wenn ja, gibt es eine bevorzugte Methode, die das Discourse-Team verwendet, um eine lokale Entwicklungsumgebung einem iPhone / DiscourseHub für Tests zugänglich zu machen, idealerweise über HTTPS?
Beim nächsten Auftreten kann ich den veralteten Beitrag auch unaktualisiert lassen und eine Bildschirmaufnahme erstellen, damit der erfolgreiche Speicher-/Serverzustand direkt mit dem verglichen werden kann, was der bereits geöffnete DiscourseHub-Client anzeigt.
Möglicherweise relevante Beobachtung
Dieses Verhalten fühlt sich auf hoher Ebene ähnlich an wie das Problem mit veraltetem Client-Zustand, auf das ich gestoßen bin, während ich an
PR #43285, “Refresh event dates in topic lists” arbeitete.
Das war ein anderer Code-Pfad, und ich behaupte nicht, dass es derselbe Bug ist.
Allerdings war der beobachtbare Fehler ähnlich: Der Server-Zustand konnte korrekt sein, während ein bereits geladener Client weiterhin einen veralteten Zustand anzeigte, bis die relevante Aktualisierung/Neu-Hydrierung stattfand.
Bei dem Problem mit den Veranstaltungsdaten konnte ich eine A/B-Situation auf verschiedenen bereits geöffneten Clients je nach Zeitpunkt beobachten.
Das lässt mich vermuten, dass dieses Bearbeitungsproblem ebenfalls irgendwo in der Benachrichtigungs-/Modellaktualisierungs-/Render-Kette liegt und nicht darin, dass die Bearbeitung selbst fehlschlägt.