2026年10月21日、セルフホストされたDiscourseインスタンスで既存の投稿を編集していた際、断続的な問題が発生しました。コンポーザー（エディタ）が保存中の状態に固定され、口述したテキストを回復するためにエディタに戻ることができませんでした。
その後、CaddyとnginxのアクセスログおよびDiscourseの投稿リビジョン履歴を確認しました。
環境
-
クライアント: iPhone 16 Pro, Safariホーム画面PWA
-
iOS: 27.0.1
-
Discourse: その日の後半の管理ダッシュボードに表示されていた通り
2026.10.0-latest +406 commits（162件の新しい変更あり） -
ホスティング: セルフホスト、プライベートな学習アーカイブ
-
リバースプロキシ: Caddy v2.11.4、QUIC上でHTTP/3を提供
-
バックエンド: Caddyの背後にあるUnixソケットを使用するDiscourse nginx
-
ネットワーク: 最初は大学のWi-Fi、その後EEモバイル通信
発生状況
物理講義のスライド画像を含む投稿を編集していました。
画像の下に分数を含む追加の数学的メモを口述し、すぐに編集を保存を押しました。
画面下部の青い横長の保存中バーが表示されたまま完了せず、消えませんでした。
保存中バーをタップしてみましたが、コンポーザーは再表示されませんでした。その結果、未保存のテキストを選択したりコピーしたりすることができず、他の場所に移すこともできませんでした。
通常より長い時間待ちました。
保存操作が既にスタックした後にのみ、Wi-Fiを手動で無効化しました。 ネットワークを切り替えることでリクエストが完了することを期待してのことです。
インターフェースは即座に復旧しませんでした。サイトロゴを使ってナビゲーションしようとした際もバッファリングが発生しました。
再び投稿を編集できるようになったとき、口述した分数は欠落していました。
サーバーサイド調査
関連する時間は、2026年10月21日のBST午後12:20頃でした。
私のCaddyログには以下が記録されています:
| 時刻 (BST) | リクエスト | 結果 |
|---|---|---|
| 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ステータス 0 |
| 12:20:55 | PUT /posts/70695 |
200 |
失敗した PUT はHTTP/3を使用していました。Caddyは約110 msの所要時間を記録しましたが、nginxはDiscourseの投稿更新コントローラーの実行なしでHTTP 400応答を記録しました。
ほぼ同じ時間に、モバイル接続から発生した多数のリクエストもまたCaddyステータス 0 を受信しました。
Caddy自体は再起動していません。Dockerは10月15日以来再起動回数がゼロと報告しており、運用ログにも対応するリロードやシャットダウンイベントはありません。
ドラフトの回復
インシデント直前には正常に完了したドラフト保存リクエストがありました。
しかし、以前のコンテンツをスライド画像だけで追加の口述テキストなしだったと記憶しています。私はその後に分数を入力し、すぐに「編集を保存」を押しました。
したがって、欠落した口述テキストがどちらかの正常なオートセーブに含まれていたことを確立することはできません。
その後、投稿リビジョンを確認したところ、12:20:55の正常なリビジョンには画像が含まれていましたが、口述された分数は含まれていませんでした。
現在のドラフトレコードも確認しましたが、検査時点で古いトピックでも新しいトピックでも残っているドラフトはありませんでした。
期待される動作
編集リクエストがスタックするか中断された場合、コンポーザーは未保存の内容を保持し、再試行、キャンセル、または編集に戻る手段を提供すると期待します。
特に、インターフェースは、「保存中」と表示しながら未保存のテキストに無限にアクセス不能にするべきではありません。
実際の動作
コンポーザーはアクセス不能のまま残り、保存中バーをタップしても再表示されず、編集再開時には口述テキストが利用可能ではなくなっていました。
質問
-
編集リクエストが保留されている間、コンポーザーが永遠にアクセス不能になることは想定されていますか？
-
ネットワークリクエストが中断された際に編集を回復するためのタイムアウトや回復メカニズムはありますか？
-
Railsの投稿更新コントローラーにリクエストが届かなかった場合でも、中断された「編集を保存」操作はメモリ内のテキストやドラフト内容を保持すべきですか？
-
iOSでこれが再度発生した場合、特定のクライアントサイドのロギングや計装（インストルメンテーション）は有用でしょうか？
最終的なリクエストのキャンセルを説明できる可能性があるネットワーク変更については理解しています。しかし、保存中インターフェースがスタックしたのは私が手動でネットワークを変更する前でした。
初期の遅延がDiscourseのJavaScript、iOS/WebKitのネットワーキング、あるいは大学の接続に起因したかどうかは特定できていません。
関連する議論
MPTCP / iOS接続継続性に関する既存のディスカッションがあり、そこでこの同じインシデントをトランスポートの観点から説明しました。
また以前、DiscourseHub on iOSで編集された投稿が時々古いままであるという問題も報告しました。その別個の問題では、編集はサーバーに正常に到達していましたが、リフレッシュするまでレンダリング済みの投稿は更新されませんでした。別のユーザーも同様の挙動に気づいたと報告しています。
これら2つの問題が共通の原因を持つかどうかはわかりません。現在のインシデントは、最初の投稿編集リクエストが正常に処理されなかった点で異なります。
また、「保存中」でスタックしたコンポーザーに関する過去の2件の報告も見つけました:
両方とも特定された原因が異なり、このインシデントを説明すると仮定していません。
選択されたCaddy/nginx診断抜粋、リビジョン情報、および上記の時系列を含むZIPファイル discourse_ios_save_evidence_2026-10-21_domain_redacted.zip|添付ファイル (6.3 KB) を添付しました。
特にネットワーク中断の前に未保存の変更をコピーできない場合、スタックしたリクエストからコンポーザーがどのように回復するよう設計されているのかについて、助言をいただければ幸いです。