追記: iOSでの投稿編集の中断とHTTP/3接続の継続性
私が以前質問していた接続継続性の問題について、具体的な実例に遭遇しました。
2026年10月21日、iPhone 16 ProでSafari PWAを使用して、私のプライベートDiscourseインスタンス上の投稿を編集していたところ、青いSavingバーが固まりました。ちょうど追加の講義ノートを音声入力で入力した直後でした。
コンポーザー（編集画面）にはアクセスできなくなっており、青いSavingバーをタップしても反応しなかったため、未保存のテキストを他の場所へコピーすることができませんでした。
通常より長く待った後、モバイル通信に切り替えるためにWi-Fiを手動で無効にしました。ページは即座に変化しませんでしたが、その後のナビゲーション試行もハングしているように見えました。
その後、Caddyとnginxのログ、および当該投稿のリビジョン履歴を確認しました。
12:20:08 BST:
-
Caddyは大学Wi-Fi接続からのHTTP/3
PUT /posts/70695リクエストを記録していました。リクエストボディの1,000バイトすべては受信済みですが、ステータスは0でした。 -
nginxは対応するリクエストをHTTP
400として記録しており、Discourseルートやアップストリーム処理時間は記録されていませんでした。 -
同じ秒に、モバイル通信から発生した他の2つのiPhoneリクエストもHTTP
400を受け取っていました。 -
その時点で成功した投稿リビジョンは記録されていませんでした。
その後の編集は12:20:55 BSTに成功しましたが、音声入力されたテキストは欠落していました。
また、12:19:44 BSTにDiscourseのドラフト自動保存が成功していましたが、そこに欠落したテキストが含まれていたかどうかは特定できません。
Wi-Fiを手動で無効にしたことが未完了リクエストを中断した可能性があることは理解しています。しかし、ネットワーク接続を変更する前に、元のSaving操作はすでに停止していました。
これにより、元の投稿に関連する2つの疑問が生じます。
-
QUIC接続マイグレーション: iOSブラウザが既存のHTTP/3接続のマイグレーションを試みたのか、それとも新しい接続を確立するか、あるいは未完了リクエストを放棄したのかを判断するための推奨方法はありますか？
-
Discourseコンポーザーの復旧: 投稿編集のリクエストが停止したり中断されたりした場合、Saving状態の背後でコンポーザーにアクセス不能になるのが想定される挙動ですか？未保存のテキストを保持すべきタイムアウト、リトライ、または復旧メカニズムは既に存在しますか？
特に2つ目の質問に関心があります。接続の復旧を試みる前に、エディタに戻って自分の作業内容をコピーできなかったためです。
このインシデントの結果として、Caddy、nginx、またはHTTP/3の設定は一切変更していません。なぜなら、利用可能な証拠だけでは、最初のSaving操作がスタックした原因をまだ特定できていないためです。