街づくり12日目・第三章｜共有DEVを止めずにcontrolを直す
2026年8月26日、街づくり12日目・第三章。
共有DEVでは、resourceを安全に切り替えるためのcontrol listenerを使います。ところがprocessが動いていても、古いsocketだけが残り、listenerへ接続できないことがあります。そこで「serverが起動中」という一つの信号ではなく、原因と影響を細かく分けました。
0人を推測しない
変更前にはauthoritative player countが必要です。複数のread-only endpointが0を返しても、control側の正本が読めなければ「たぶん0人」へ昇格させません。取得不能、値の不一致、接続中の可能性が残る場合は、その場で停止します。
同じように、active sourceとtracked rollbackが分からない状態ではresource adoptionへ進みません。戻り先がないまま変更を始めると、成功判定も失敗時の復旧も曖昧になるからです。
stale socketだけを対象にする
復旧対象は、所有者、path、inode、service identityが期待値と一致するstale socketだけです。別processが使うsocket、listenerが存在するsocket、所有境界が不明なfileは削除しません。
さらに、FiveM全体を再起動しないcontrol専用経路を用意しました。listenerが競合を検出した場合はbounded retryを行い、同じfailureが続くなら停止します。manual consoleや未文書APIへ迂回せず、review済みのplanとapplyを分けます。
復旧codeとruntime成功を分ける
failure-first testでは、player確認、対象socket fingerprint、process identity不変、listener read-back、cleanup、rollbackの欠落を拒否します。ただしcodeがmergeされたことは、共有DEVのlistenerが実際に復旧した証拠ではありません。
runtimeでの最終実証は別のtransactionです。exact plan、0人の再確認、実行承認、復旧後diagnosticが揃うまで、resource activationやdatabase操作へ進みません。