編集した投稿が正常に保存されるものの、iOS版DiscourseHubで既にレンダリング済みの投稿が、トピックをリフレッシュするまで古い状態のままになることが時々あるという断続的な問題に遭遇しています。
環境
本番サイトは、個人的な学習アーカイブとしてプライベートで利用している、セルフホストされたDiscourseインスタンスです。
本日この問題を再現した時点での環境は以下の通りです：
- クライアント: iPhone上のDiscourseHub
- iOS: 27.0.1
- 本番Discourse:
v2026.10.0-latest +112 - サイト: セルフホスト、プライベートな学習アーカイブ
- iOSの既定のブラウザ: iCab Mobile
無関係なローカルダウンロードの問題があるため、既定のブラウザをiCab Mobileに変更しました。しかし、この再現は外部ブラウザを開いた後ではなく、DiscourseHub内でDiscourseサイトを使用している際に発生したため、現時点では既定のブラウザの選択が関連しているとは考えていません。
実際のワークフロー
この問題に気づいたトピックには、講義スライドを表す約50件の投稿が含まれていました。
通常のワークフローは以下の通りです：
- 講義スライドの画像を含む投稿を作成する；
- その後、トピックを順番に処理する；
- 各既存の投稿を編集する；
- 既に投稿されたスライド画像の下にOCRトランスクリプト／メモを追加する；
- Save Edit（編集を保存）を押して、次のスライドに進む。
したがって、これらは合成された高速編集ではなく、講義スライド画像の投稿にOCRトランスクリプトを段階的に追加していく通常の学習ワークフローです。
トピックの前半の投稿では、Save Editを押すと、期待通りに表示されている投稿が新しい編集内容に即座に置き換えられました。
同じトピックの後半で、以下のようなケースに遭遇しました：
- 投稿を編集し、OCRテキストを追加した。
- Save Editを押した。
- 編集は正常に保存された。
- DiscourseHubに表示された投稿は、以前の内容のままだった。
- ページをリフレッシュすると、既に保存済みの編集が即座に表示された。
つまり、編集自体は成功したように見えます。古い状態のままなのは、投稿の既に読み込まれたクライアント側の表現のようです。
開発環境でのテスト
その後、現在のアップストリームの main から完全にクリーンな開発インスタンスを作成しました：
833e1576d47 DEV: Update README.md note on self-hosting (#44320)
本番トピックの構造を模倣するために、すべての投稿に画像を含む60件の投稿からなるトピックを生成しました。
その後、Linux上のFirefoxでワークフローを繰り返し、既存の画像投稿にテキストを編集して入力しました。
最初のテストでは、投稿19付近で1件の古い更新の可能性を見ました。しかし、実験をより慎重に繰り返した結果（新しい60投稿トピックを作成し、投稿を連続して編集するなど）、現在のmainではFirefox/Linuxで本番環境の挙動を再現できませんでした。
そこでは、Save Editの後に投稿が即座に再描画されました。トピックの最初の投稿グループをはるかに超えた範囲でも同様でした。
これにより、トピックのページネーションや通常の20投稿ストリームチャンク自体が原因であるという確信が薄れました。
次のテスト
本番環境での再現は、ホーム画面PWAではなく、iOS上のDiscourseHubで行われました。
したがって、次の予定している比較は以下の通りです：
- 現在のアップストリームのDiscourse開発インスタンス；
- 同じ60投稿の画像トピック；
- 同じiOS 27.0.1を搭載したiPhone；
- まずDiscourseHub；
- 同じiPhone上のSafariを対照として；
- 必要に応じて、ホーム画面Webアプリを別の比較対象として；
- 同じOCRスタイルのワークフローを使用して、投稿を連続して編集する。
現在、開発用ラップトップはeduroamに接続しているため、そのローカル開発サーバーをiPhoneに直接公開するのは容易ではありません。
この問題を絞り込むための次のステップとして、現在のmainの開発インスタンスを同じiPhoneでDiscourseHubで実行するのは正しいアプローチでしょうか？
もしそうであれば、テストのためにローカル開発インスタンスをiPhone / DiscourseHubに公開する（できればHTTPS経由で）Discourseチームが好む推奨方法がありますか？
次に発生した際、古い投稿をリフレッシュせずに残し、画面録画を取得することで、正常に保存されたサーバーの状態と、既に開いているDiscourseHubクライアントが表示している内容を直接比較できます。
関連する可能性がある観察
この挙動は、PR #43285, “Refresh event dates in topic lists” で作業中に遭遇した古いクライアント状態の問題と、高レベルでは似ていると感じます。
それは別のコードパスであり、同じバグであるとは主張していません。
しかし、観察可能な障害は類似していました：サーバー側の状態が正しくても、関連するリフレッシュ／再ハイドレーションが発生するまで、既に読み込まれたクライアントが古い状態を表示し続けることがありました。
イベント日付の問題では、タイミングによって異なる既に開いているクライアント間でA/B状況を観察できました。
これにより、この編集の問題も、編集自体の失敗ではなく、通知／モデル更新／レンダリングチェーンのどこかにあるのではないかと疑問に思っています。