fix(cli): a running run is not a protocol error (#179)

[kjgbot]

Fixes the live-kernel > follows a live worker dispatch through flows run flake from #179, which failed CI three times tonight and forced a re-run each time.

Reproduced first

Built a worktree at main's tip to CI's own spec and ran the test in a loop: 1 failure in 12, then 1 in 4 on a second pass. Instrumenting the fall-through branch named the state exactly:

PROBE_D unclassifiable inspection={"status":"running","needsHuman":false}

The bug

classifyOutcome loops while the run is parked, asking inspectOutOfBandStep what to do next. That helper reports a step only when a non-deterministic step is needs_human, runnable or running.

When a worker has just completed the step the run parked on, there is a window where none of those hold while the snapshot's own status is still running — the daemon has not yet finished driving what follows. Every branch missed that window, so the loop broke with status === 'parked' and no parkedStep, and the tail reported:

FAILED [protocol_error] relayflowd could not complete the run request:
relayflowd returned status parked without a classifiable completion

The run was healthy and about to succeed. The CLI failed it for being observed mid-stride.

The fix

A run that reports running is progressing, so it is polled rather than abandoned — bounded at 40 × 50ms = 2s, far longer than the sub-second window observed and short enough that a genuinely stuck run still reports instead of hanging. The unchanged break below keeps it failing closed if it never resolves.

Evidence

	result
before	1 fail / 12, then 1 fail / 4
after	0 fail / 40
full SDK suite	31 files passed, 649 tests passed, 3 skipped
typecheck	clean

This also explains the cli-hn-monitor failure shape from #179's table: both are the CLI treating a transient, healthy state as terminal. Worth re-checking that one once this lands.

Note on the unprovable_effects warning

Both CI failures quoted WARNING [unprovable_effects] Step "greet" command "printf"... in their assertion message. That is a red herring — it appears in stderr on every run, passing or failing, and is simply the first line of the captured stderr the assertion prints. The real error was always the protocol_error beneath it.

Reproduction environment

Not obvious, and it cost me a tick to get right: surface must be installed and built before the sdk, with bun (bun install --frozen-lockfile --ignore-scripts && bun run build) — npm fails there because surface has no package-lock.json. Then npm ci --prefix sdk --ignore-scripts, a release relayflowd for RELAYFLOWD_BIN, and RELAYFLOWS_ALLOW_ANALYZER_SKIP=1.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR

[coderabbitai]

Warning

Review limit reached

Next included review available in 18 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

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).

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Free

Run ID: 6abb343c-8db3-406b-9dec-56b0e8d2a167

📥 Commits

Reviewing files that changed from the base of the PR and between e0ecae3 and ae04d2a.

📒 Files selected for processing (2)

• sdk/src/cli/run.ts
• sdk/tests/classify-outcome.test.ts

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing.

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