Conversations のライターロックとリカバリ

更新されたデーモンは Conversations を共有し、異なるセッションを同時に使用できます。ロードされたセッションには引き続き1つのライターが存在します。Live アクティベーションは安定した Live ロケーターの正確なパブリッシャーのみに属します。Live パブリケーションを失ってもスタンドアロンの Conversations は無効になりません。

Conversation が開かない

session_writer_conflict はライターフェンスがアクセスを妨げたことを意味します。別のプロセスが conversation を開いているか、残存するロックを安全に回収できないことを示している可能性があります。別のライターが現在アクティブであるという証明ではありません。session_writer_unavailable は所有権を検証できなかったことを意味します。リトライしてもそれをバイパスする許可にはなりません。アーカイブと削除は、個別のセッションに対してライターエラーと共に HTTP 200 を返すことがあります。すべての結果項目を確認してください。

所有する Qwen プロセスで通常通り conversation を閉じ、次に影響を受けた conversation で Try again を使用してください。他のセッションは引き続き使用できます。エラーを消すためだけに代替 conversation を作成しないでください。

非グレースフルなシャットダウン後、Linux の再起動または新しい PID 名前空間へのコンテナ再起動により、シールされていないアクティブなライターレコードが無限にフェンスされたままになる可能性があります。閉じるための存続するオーナーが存在しない場合があります。繰り返しリトライする代わりに Operator recovery for a residual lock に従ってください。このリリースでは、それらの ID 境界を越えた自動回収は行われません。

問題が継続する場合は、影響を受けたデーモンの起動時にローカルデバッグログ（QWEN_DEBUG_LOG_FILE=1）を有効にし、デーモンと ACP 子プロセスの診断を確認してください。リース取得の診断には、セッション ID、エラーの種類、およびそのライターのランタイムストレージから解決された正確な lockPath が含まれます。プライマリワークスペースまたはデフォルトのホームディレクトリからロックパスを推測しないでください。パブリック HTTP/ACP エラーは意図的にパスと所有権レコードを省略しています。診断ファイルは非公開に保ってください。オーナートークンや編集されていないロック内容を公開しないでください。

どの状態が自動的にリカバリできるか？

これらのルールはセッションライターリースに適用されます。レガシーのグローバルオーナーレコードは、以下で説明するより限定的な互換性チェックを使用します。

通常クローズはリースを解放します。認証済みのシールされたハンドオフは、トランスクリプトの証明がまだ有効な場合にのみ受け入れられます。
死亡したアクティブライターは、既存の ID チェックによりそのプロセスが同じ検証済み liveness ドメインに属することが確認された場合にのみ回収可能です。
Live またはストールしたライターはフェンスされたままです。デーモンを kill しても、ACP ライター子プロセスが存続している場合は不十分です。
外部または欠落したブート/プロセス名前空間の ID は死亡の証明ではありません。名前空間内に PID が存在しないことは、外部ライターが終了したことを証明しません。
不正な形式のレコード、不確かなトランスクリプト ID、および残存するトランジション要求は fail closed（失敗時は拒否）となります。経過時間だけではテイクオーバーは承認されません。

残存ロックのオペレーターリカバリ

ローカル診断から正確な影響を受けたセッションとストレージを特定します。失敗ログと、そのトランスクリプトおよびロック成果物のプライベートバックアップを保存します。どのバイナリとホストがこのストレージにアクセスできるかを記録します。
デタッチされた ACP 子プロセス、他のデーモン、コンテナ、名前空間、およびファイルシステムを共有するマシンを含む、考えられるすべてのライターを停止またはその他の方法でフェンスします。関連するホスト/名前空間からフェンスを検証します。これが確立できない場合は、ここで停止して、可能なオペレーターに問い合わせてください。
メンテナーと共に正確なレコードおよび関連する claim/retired 成果物を検査します。最後のトランスクリプトとハンドオフの証明が信頼できるかどうかを判断します。所有権 ID フィールドを編集して一致を捏造しないでください。
ライターがフェンスされ、証拠がバックアップされた後にのみ、オペレーターの監督下で個別に検証された残存成果物をプライベートリカバリストレージに移動します。ロックディレクトリを再帰的に削除したり、すべてのロックを削除したりしないでください。
更新されたデーモンを1つ起動し、元のセッションを復元し、追記前に最後に記録されたターンを確認します。継続性が確認されるまでバックアップを保持します。その確認後にのみ、他の更新されたデーモンを復帰させます。

このリリースには force-unlock API や自動クロスブート/TTL テイクオーバーはありません。安全な所有権を確立できない場合は、フェンスを維持してください。

調整されたアップグレードとロールバック

バックエンドの切り替えと Web Shell のローカルエラー/リトライの変更は、同じリリースで出荷する必要があります。これは混合バージョンのローリングアップグレードではありません。更新されたデーモンがすでに起動した後に、古いデーモンがグローバルオーナーを作成する可能性があります。

アップグレード前に、すべての古いセッションとスケジュールされたワークを drain し、すべての古いデーモンとその ACP 子プロセスを停止し、ランタイムデータを保存してから、更新されたバイナリを起動します。Live のレガシーオーナーに遭遇した更新されたデーモンは 503 conversation_runtime_in_use を返します。そのオーナーが終了した後、再起動せずにリトライしてください。正確に再検証された古いレガシーレコードのみが retired されます。不正な形式または安全でないレガシー状態はオペレーターの調査が必要です。

レガシーの conversations/runtime-owner.json レコードには PID と nonce が含まれていますが、ホスト名、ブート ID、または PID 名前空間の ID は含まれていません。その互換性チェックは、その PID が更新されたデーモン自身のホストおよび PID 名前空間に存在するかどうかのみをテストできます。共有ストレージ上の他の場所でアクティブな古いライターを検出することはできません。これは、更新されたデーモンを起動する前に考えられるすべてのライターをフェンスする別の理由です。このチェックでは混合ホストまたは混合名前空間のアップグレードが安全になるわけではありません。

ロールバック前に、更新されたすべてのデーモンとライターも drain およびフェンスしてください。アクティブ、シール済み、claim、retired、および拡張スキーマのレコードをインベントリします。ターゲットバイナリが保持された各スキーマとハンドオフ状態を理解していることを確認してください。サポートされていないスキーマを古いライターに渡したり、ロールバックを進行させるために保護レコードを削除したりしないでください。互換性を確立できない場合は、ライターを停止したままにし、メンテナーがガイドするリカバリまたは一貫性のあるアップグレード前のバックアップを使用してください。後の権威あるターンを明示的に考慮せずに、古いトランスクリプトを復元しないでください。