fix: keep docker ps off the discord.py event loop in status_cog

[welshDog]

Last of the sync-I/O-on-an-async-loop fixes (#309, #310, #311, #312).

The change

StatusCog.status() is a discord.py command coroutine that called subprocess.run(["docker","ps"], timeout=10) directly. On the bot's event loop that stalls the gateway heartbeat and every other command with it. Wrapped in asyncio.to_thread.

FileNotFoundError, subprocess.TimeoutExpired and the generic handler below all still catch — to_thread re-raises in the awaiting coroutine.

Verification

Run inside the running broski-bot container (discord.py 2.4.0), loading the module and driving the real StatusCog.status.callback with a fake context. Same harness against the pre-fix code from main as a control:

	control	fixed
2s blocking subprocess	1999.9 ms loop stall	1.7 ms loop stall
real call (no docker CLI)	❌ Docker CLI not found	❌ Docker CLI not found

The real call producing the identical embed on both sides proves the exception path survives the thread hop.

Scope — stated plainly, because it matters

This cog is not loaded. cogs.status_cog is absent from the COGS list in cogs/bot.py, and nothing imports it:

references to status_cog in bot.py: 0
files importing it:                 none

The image also ships no docker CLI (command -v docker → not found), so even if the cog were loaded, the subprocess would raise FileNotFoundError immediately rather than block for 10s.

So this is correctness insurance for whenever someone wires the cog up. It is not repairing a live fault. I originally reported it as "blocking your live Discord bot" — that was wrong, and it was wrong because an AST sweep flags files, not executed code.

Deliberately NOT changed: agents/hyperhealth/main.py:111

The same sweep flagged subprocess.run(["alembic","upgrade","head"], timeout=30) there. It is inside async def lifespan(), and app = FastAPI(..., lifespan=lifespan) — uvicorn runs lifespan before it accepts connections. Blocking a loop that isn't serving anything costs nothing, and asyncio.to_thread would change literally nothing. A false positive in practice.

But the logs there exposed something real (not fixed here)

The hyperhealth container command is:

sh -c alembic upgrade head || alembic stamp 001 && exec uvicorn main:app ... --workers 2

• --workers 2 forks two uvicorn workers, each running lifespan, so alembic upgrade head runs once per worker — concurrently. Confirmed in the logs: two hyperhealth.startup events and two migrations_completed events per boot.
• The CMD already ran alembic upgrade head once before uvicorn started. Migrations execute three times per boot.
• On 2026-06-24 all of them timed out (Command '['alembic','upgrade','head']' timed out after 30 seconds) and were swallowed as level: warning. Today's boot succeeded, and alembic current reports 001 (head), so the DB is fine — but the failure mode is silent.
• The || alembic stamp 001 fallback re-stamps the version table on failure, which is exactly the operation the project notes say never to perform against the shared alembic table.

Worth its own issue and its own change; not bundled in here.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@welshDog, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 14 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f8b2500d-59ab-495f-a5a1-199f4aa40bf6

📥 Commits

Reviewing files that changed from the base of the PR and between 798a565 and 812312c.

📒 Files selected for processing (1)

• agents/broski-bot/cogs/status_cog.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/broski-bot-status-cog-blocking

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}