起動の待ちの制限時間（60 秒）が実際の時間ではなく巡の回数で数えられている #374

何を見つけたか

devbase up / devbase scale の起動の待ち（wait_for_containers_ready）は、制限時間 timeout=60 を実際の時間ではなく巡の回数で数えている。

• 1 巡で、まだ決まっていない番号ごとに状態の確認（docker compose ps）と、動いていれば完了の確認（docker compose exec ... test -f）を行い、その後に 1 秒休んで回数を 1 増やす。起動できた・終了した・見つからないと決まった番号へは、その後の巡で問い合わせない
• 回数が 60 に達した時点で完了を確かめられていない番号は、timeout (60s) waiting for the entrypoint to complete として ContainerStartupError に入る
• docker の呼び出しにかかる時間は回数に入らないため、実際に待つ時間は 60 秒より長い。まだ決まっていない番号が多いほど、接続先が遠い（リモートの docker context）ほど長くなる
• 1 台が起動できなくても、残りの番号は制限まで待つ（up でコンテナが 1 台でも落ちると、起きているコンテナにも起動の後の処理（window.title・token・エディタ）が行われない #371）。1 台が落ちた up / scale は最長で制限まで延びるため、このずれが利用者の待ち時間にそのまま出る

実測はしていない。コードの読み取りで確かめた（main = d433e55）。

$ sed -n 272,292p lib/devbase/utils/docker.py
    while pending and rounds < timeout:
        ...（まだ決まっていない番号の状態の確認と完了の確認）...
        pending = still_pending
        if not pending:
            break
        time.sleep(1)
        rounds += 1

この数え方は確定仕様とテストにも書かれている。

どこで見つけたか

#224・#371 の設計（確定仕様 docs/specifications/post-start.md）で、起動の待ちの振る舞いを読んだときに見つけた。

なぜこの変更の範囲外なのか

#224 の要求の前提 4 が「制限時間（60 秒）は変えない」と定めている。数え方を実際の時間へ変えると、今は通っている遅い起動（初回の clone が長い・接続先が遠い）が時間切れになり得るため、#224 の変更では巡の回数のまま残した（設計の決定 8）。

根拠: Vision（MVV 版 1）。どの端末でも同じ結果になることを目指すが、今の数え方では、待てる長さが端末と接続先の速さで変わる。

直さないと何が起きるか

• 時間切れの文言の 60s と、実際に待った時間が合わない。利用者は 60 秒で止まったと読むが、実際はそれより長く待っている
• 待てる長さが、インスタンスの数と docker の呼び出しの速さで変わる。同じプロジェクトでも、手元では間に合い、リモートでは間に合わない（またはその逆）ことが起こり得る
• 実害の観測はまだ無い。実際の時間で数えるなら、制限の値（60）を今の実質の長さに合わせて見直す必要がある

直す場所

由来

issue #224

受け入れ条件

2026-10-13 スプリント m8d の要求として書いた（設計なし）。2026-10-13 の利用者の決定（数え方は変えず、文言だけを直す）に従う。

進行

モード: —

• 要求と受け入れ条件
• 作業場所の用意 — 2026-10-14 09:42
• 設計
• 素材の収集と出典の確定
• ドキュメント再構成
• ドキュメントレビュー
• 計画 — 2026-10-14 09:42
• 実装 — 2026-10-14 10:09
• 構造改善 — 2026-10-14 10:18
• 実装レビュー — 2026-10-14 10:36
• 完了判定 — 2026-10-14 10:13
• Pull Request — 2026-10-14 10:15
• 確定仕様化 — 2026-10-14 12:38
• 後片付け
• 配布 — 2026-10-14 13:52
• 体裁レビュー
• リリース後テスト — 2026-10-14 13:53
• 振り返り — 2026-10-14 13:58
• 棚卸し — 2026-10-15 13:18

振り返り: #488 (comment)