Hmbown/CodeWhale · error · anyhow::Error
{}: {detail}
Error message
{}: {detail} What it means
emit_fleet_receipt is the single exit point for fleet control operations on the CLI. When the shared ControlReceipt comes back marked error (is_error), the receipt is rendered to stderr and the command bails with '<operation_id>: <detail>', where detail is the receipt's failure text or its outcome string. A worker-side failure therefore becomes a non-zero CLI exit while preserving the operation id for correlation.
Source
Thrown at crates/tui/src/lib.rs:2908
fn print_inspection(inspection: &FleetWorkerInspection) {
println!("{}", fleet_control::render_inspection(inspection));
}
fn print_artifacts(inspection: &FleetWorkerInspection) {
println!("{}", fleet_control::render_artifacts(inspection));
}
/// Print one shared control receipt on the CLI surface.
fn emit_fleet_receipt(receipt: &codewhale_lane::ControlReceipt) -> Result<()> {
if receipt.is_error() {
eprintln!("{}", receipt.render());
let detail = receipt
.failure
.as_ref()
.map(ToString::to_string)
.unwrap_or_else(|| receipt.outcome.as_str().to_string());
bail!("{}: {detail}", receipt.operation_id);
}
println!("{}", receipt.render());
Ok(())
}
fn print_logs(workspace: &Path, inspection: &FleetWorkerInspection) -> Result<()> {
let mut printed = false;
for artifact in inspection
.artifacts
.iter()
.filter(|artifact| matches!(artifact.kind, FleetArtifactKind::Log))
{
let path = workspace.join(&artifact.path);
println!("== {} ==", artifact.path.display());
let contents = std::fs::read_to_string(&path)
.with_context(|| format!("reading fleet log {}", path.display()))?;
let preview: String = contents.chars().take(16 * 1024).collect();
// Worker logs can contain captured terminal bytes (a child TUI'sView on GitHub (pinned to 0c42157ee5)
Solutions
- Note the operation_id and the detail text; re-run the fleet inspection/logs step to see worker-side artifacts for that operation
- Verify the fleet worker is running and reachable in the target workspace before issuing control
- Fix the underlying failure named in the detail, then re-run the same control operation
- Script defensively: check worker status first and treat this bail as an actionable failure, not a retryable transient
Example fix
# before codewhale fleet <control-cmd> # op-1234: worker unreachable # after # 1) inspect fleet artifacts/logs for op-1234 # 2) start/repair the worker, then re-run the same control command
Defensive patterns
Strategy: try-catch
Validate before calling
# Verify worker health before issuing control operations
codewhale fleet status >/dev/null 2>&1 || { echo 'fleet worker not healthy'; exit 2; } Try / catch
if ! out=$(codewhale fleet <control-cmd> 2>&1); then op_id=$(printf '%s' "$out" | head -1 | cut -d: -f1) echo "control operation $op_id failed; inspect fleet logs/artifacts" >&2 exit 1 fi
Prevention
- Check fleet worker status before each control batch
- Correlate failures by the operation_id printed in the bail
- Do not blind-retry; the receipt's failure detail names the cause
When it happens
Trigger: Any fleet control operation whose receipt reports error: the fleet worker not running or unreachable in that workspace, the control payload rejected, or the operation failing on the remote side. The bail carries the operation_id and the receipt's failure/outcome detail.
Common situations: Remote control scripts hitting a stopped or crashed worker; fleet operations against stale workspaces; CI steps that issue control commands without first verifying worker health.
Related errors
- pass --all to stop all fleet work
- The Codewhale service returned an unexpectedly large respons
- Codewhale account login timed out; run `codewhale account lo
- The Codewhale service returned an account without an ID
- Not signed in. Run `codewhale account login` first
AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20).
Data as JSON: /api/errors/c76d6d47232e9898.
Report an issue: GitHub.