Strix CI runs fail/hang from two compounding infra issues: Caido sandbox bootstrap race + silent LLM provider unreachability

[mmango10]

Two compounding infra failures running Strix in GitHub Actions CI: (1) strix-sandbox container intermittently fails to start due to a Caido proxy bootstrap race (same root cause as #830; #831 only reaps the leaked container after failure, doesn't fix the race itself), and (2) separately, when the LLM provider endpoint (NVIDIA NIM/Nemotron) is network-unreachable from the runner's egress IP, Strix hangs silently with no distinct error — it just runs until the job-level timeout kills it, giving no signal that it's a connectivity problem vs. a slow scan.

To Reproduce

1. Run strix-security workflow in GitHub Actions using strix-sandbox:1.0.0 (or 1.1.0) as the sandbox image, pointed at a self-hosted/NIM-backed LLM endpoint.
2. Observe intermittent job failures from Caido proxy bootstrap race inside the sandbox (same trigger conditions as [BUG] Sandbox container leaks when Caido bootstrap or port resolution fails before the session is cached #830).
3. Separately, if the runner's egress IP is blocked/rejected by the LLM provider (e.g. NVIDIA blocking a GH Actions IP range), trigger a scan and observe it hang with no error until the overall job timeout is hit — no reachability check or distinct timeout fires earlier.
4. Attempt to downgrade strix-sandbox version to dodge the Caido race, and separately observe SARIF output shape differs between 1.0.4 and 1.1.0, breaking downstream SARIF parsing/summary scripts across versions.

Expected behavior

• Caido bootstrap race doesn't occur, or fails fast with a clear, distinct error rather than a container leak requiring fix(runtime): reap the sandbox container when Caido bootstrap fails #831's reaping fix.
• SARIF output schema stays stable across sandbox image versions, or schema changes are called out in release notes.
• Strix performs an early, fast reachability check against the configured LLM provider endpoint and fails with a clear "provider unreachable" error (ideally including the runner's egress IP) instead of hanging until the overall job timeout.

Screenshots
N/A (CI logs only, can attach on request).

System Information:

• OS: Ubuntu 22.04 (GitHub Actions ubuntu-latest runner)
• Strix Version or Commit: sandbox image strix-sandbox:1.0.0 / 1.1.0 (downgraded to 1.0.4 as workaround)
• Python Version: N/A (containerized CI run, not run locally)
• LLM Used: NVIDIA NIM (Nemotron)

Additional context
Relates to #830 (Caido bootstrap race) and #831 (fixes container leak only, not the race). Repro workflow run: 30305655129, ItemTraxxCo/itemtraxx-code PR #775. Diagnosed the LLM-unreachability case by manually adding curl to the NIM endpoint + ifconfig.me debug steps directly into our workflow YAML — Strix itself gave no indication the issue was network/provider-side.

[shraav185]

I am interested in solving this issue, can you assign this to me ?

[mmango10]

I am interested in solving this issue, can you assign this to me ?

I don't have the necessary permissions to modify the issue

[bearsyankees]

Was this on latest strix version @mmango10 (1.4.1?)

[mmango10]

Was on 1.1.0 (pinned in our workflow), not latest. Will retest on 1.4.1 and report back if issues still repro.

[mmango10]

Confirmed fixed on 1.4.1. Bumped our pin from 1.1.0 → 1.4.1 and reran the workflow twice on our branch — no more "Could not acquire a connection to the database" from Caido, and the NIM LLM warm-up call connects and completes cleanly (0 hangs, scan finishes in ~7-8min as expected). One rerun hit a transient ResourceExhausted rate-limit from our own NIM key, unrelated to Strix — retry succeeded immediately.

Re-enabled the scan in our CI. Closing this out on our end — thanks for the fix.

[bearsyankees]

Great, closing as fixed!