wait_for_octobot_ready

Poll for OctoBot's HTTP server becoming reachable again after a restart.

A bounded retry loop against GET /api/version (see this module's docstring for why this specific route was chosen) -- never blocks past timeout_seconds, and never raises for a timeout: that is a normal, honestly-reported result (NFR-3's "honest null/false over a fabricated guess" ethic), matching every other timeout-bounded loop in this project.

Correctness fix (resolving part of open question #14, live-verified against the test instance): a ready: true result now REQUIRES having observed at least one genuinely unreachable poll first. An earlier version of this tool returned ready: true after its very first poll succeeded -- but restart_octobot's own route schedules OctoBot's kill with a confirmed ~2-second delay (models.restart_bot(delay=2), ADR-0010's Context), so a poll issued immediately after restart_octobot returns will almost always land WITHIN that grace window and hit the OLD, not-yet-killed process -- a false positive that completely defeats this tool's purpose. Confirmed live, twice, against the OctoBot 2.1.1 test instance: the HTTP server stayed reachable until ~2.1s post-trigger (matching the confirmed 2s delay almost exactly), then was genuinely unreachable for ~6.3-6.7s, before answering again at ~8.5-8.9s total. A naive first-success-wins loop reported ready: true in ~0.05s both times -- entirely within the pre-kill grace window, never having observed the real restart at all. This loop now tracks whether it has seen a failed poll; a success only counts as ready: true once at least one prior poll in this same call has failed, so ready: true now means "the server went down and came back," not just "answered."

"Ready" (even with the fix above) still means ONLY "the HTTP server answered a request again after a confirmed outage" -- nothing more, and this is now a CONFIRMED gap, not a suspected one. A follow-up live test checked SimpleStrategyEvaluator's default_config/ required_evaluators immediately after a genuine, confirmed restart (dense-polled, not a race) -- unchanged from before the restart. The same end result (restart does not unblock strategy-composition-tuning validation via backtest) was independently confirmed on an entirely separate OctoBot instance/session. Do not present restart_octobot/ wait_for_octobot_ready as a fix for evaluator/strategy-composition tuning validation -- that was this capability's whole stated purpose (ADR-0010's Context) and it does not hold. See ADR-0010's "Negative finding" (Context) and Consequences for the full account, including an open question of whether this capability should be kept at all given its purpose doesn't hold. Order-execution parameters (sizing, stop-loss/take-profit) are unaffected by any of this and apply correctly in a profile_id-targeted backtest without a restart.

DEFAULT_TIMEOUT_SECONDS/DEFAULT_POLL_INTERVAL_SECONDS (60s/2s): the 60s timeout has real headroom above the ~8.5-8.9s measured end-to-end restart time above (measured twice, one instance, one OctoBot version -- some margin is appropriate, not treated as a tight bound); the 2s poll interval reliably samples within the ~6.3-6.7s measured outage window. Still treat both as informed-but-limited defaults (n=2, single instance/version), not a guaranteed bound for every OctoBot deployment -- override both per-call if your own environment differs materially.

Not confirm-gated (a read-only poll). Returns {"ready": true|false, "elapsed_seconds": float, "attempts": int} -- all fields reflect this loop's REAL timing/attempt count, never fabricated.