fix: bound Caido readiness probe by wall-clock deadline, not fixed attempts - #1056
fix: bound Caido readiness probe by wall-clock deadline, not fixed attempts#1056roshanaryal1 wants to merge 2 commits into
Conversation
…tempts _login_as_guest() retried loginAsGuest exactly 10 times with capped exponential backoff (~68s total), regardless of how long the sandbox actually took to boot Caido. The sandbox entrypoint chowns a large toolchain tree before starting caido-cli, which can take minutes on a loaded host or CI runner, so every scan there failed before a single LLM call was made. Replace the fixed attempt count with a wall-clock deadline, configurable via STRIX_CAIDO_BOOT_WAIT_S (default 180s). Fast hosts are unaffected; slow/shared hosts and CI runners can raise the budget instead of hitting a hardcoded ceiling. The error message now reports elapsed time and attempt count instead of just attempts. Fixes usestrix#1036, usestrix#1037
Greptile SummaryThe PR replaces Caido’s fixed readiness-attempt limit with a configurable monotonic-time budget and threads the new runtime setting through session creation.
Confidence Score: 4/5The readiness fix should be adjusted before merging because the configured wall-clock deadline can still be exceeded by the final curl attempt. The retry loop checks expiration only after a fixed-timeout exec, so a request started near the deadline can keep session creation blocked for almost 15 additional seconds and produce an inaccurate elapsed-time diagnostic. Files Needing Attention: strix/runtime/caido_bootstrap.py, tests/test_caido_bootstrap.py Important Files Changed
|
Greptile review on usestrix#1056: the fixed 15s curl timeout wasn't bounded by the remaining wall-clock budget, so an attempt starting just before the deadline could block session creation for up to 15s past STRIX_CAIDO_BOOT_WAIT_S, and the resulting error would understate the actual elapsed time. Move the deadline check to the top of the loop and pass min(15, remaining) as the per-attempt timeout.
|
Good catch — fixed in 21e5ae0: the deadline check now happens before each attempt, and the per-attempt curl timeout is capped to |
Summary
_login_as_guest()instrix/runtime/caido_bootstrap.pyretriedloginAsGuesta fixed 10 times with capped exponential backoff (~68s total), independent of how long the sandbox actually took to boot Caido.chown -Rover a large pre-installed toolchain tree before startingcaido-clion port 48080. On a loaded host or CI runner this is deterministically slow (one report measured ~27 minutes), so scans there fail before a single LLM call is ever made, with a genericcurl exit 7error that reads like a local network problem rather than a slow sandbox boot.STRIX_CAIDO_BOOT_WAIT_Ssetting (default180s). Fast hosts are unaffected — the loop still returns as soon as Caido is reachable. Slow/shared hosts and CI runners can raise the budget via env var instead of hitting a hardcoded ceiling.Changes
strix/config/settings.py— newRuntimeSettings.caido_boot_wait_sfield (STRIX_CAIDO_BOOT_WAIT_S, default 180.0)strix/runtime/caido_bootstrap.py—_login_as_guestloops againsttime.monotonic()deadline instead ofrange(1, attempts+1);bootstrap_caidogains aboot_wait_sparamstrix/runtime/session_manager.py— passesload_settings().runtime.caido_boot_wait_sthrough tobootstrap_caidotests/test_caido_bootstrap.py— new tests: succeeds once Caido comes up mid-retry, and respects the configured deadline (raises with elapsed-time message, not "after N attempts")Fixes #1036, and should also resolve the GitHub Actions failure in #1037 (same root cause — CI runners are exactly the "loaded host" case the fixed 68s budget can't cover).
Test plan
uv run pytest tests/test_caido_bootstrap.py -v— new tests passuv run pytest tests/— full suite (888 tests) passes, no regressionsuv run ruff check/ruff format --check— cleanuv run mypyon changed files — cleanchown -Rboot locally)🤖 Generated with Claude Code