FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
Thread接続直後に初回同期する
周期処理を待つ間のRoom割当raceを、単一のin-flight同期で閉じる
目的
接続設定を確定しても、次の30秒周期同期が終わるまでroot Threadがdatabaseへ存在せず、直後のRoom割当が失敗する時間差があった。設定適用と同期完了が画面上では一続きに見えるため、管理者が正しい手順でも先へ進めない状態になっていた。
接続設定の適用直後に初回同期を実行し、周期同期と重なってもApp Server読込みとoutbox送信を二重化せず、Room割当前に同期結果を確認できるようにすることを目指した。
実装
command入口に、実行中の同期Promiseを共有するsynchronizeを追加した。apply直後と30秒周期処理は同じ入口を使い、すでに同期中なら新しい処理を開始せず、そのin-flight operationの結果を待つ。
同期制御serviceはsync-target-applyの設定反映後にsynchronizeNowを呼ぶ。accepted、deferred、failureをbounded logへ分け、初回同期が失敗しても有効な接続設定は保持して周期処理の再試行へ委ねる。
管理applicationではapply後にConnector statusを再取得し、最終同期結果を表示する。acceptedでなければ、Roomへ割り当てる前にConnector状態の確認と再試行が必要だと案内する。
同期制御serviceを、明示的な追加同期なしでもapply処理から対象rootが収集されることと、結果がstatusへ出ることを確認する形へ更新した。
図を描画しています…
確認したこと
確認結果
修正前はapplyから次回周期同期までに時間差があり、その間のRoom割当が失敗することを実測した。
修正後は新しいConnectorで接続設定1件、初回同期accepted、保留outbox 0を確認した。
対象TypeScript test 5件、Swift test 21件、仕様監査、差分検査が成功した。
cutoff時点でapply直後の同期と結果表示は対象へ反映され、周期処理を待たずにRoom割当の前提を整えられる状態になった。
完了とした根拠
apply直後の同期が周期同期と同じin-flight operationを共有し、実際のroot Threadがacceptedとして保存され、status表示と対象testで結果を確認できたことを完了基準とした。