wildcard/caro

ai: caro ai --once provides zero user feedback during model initialization

Open

#1,408 opened on Aug 15, 2026

 (1 comment) (0 reactions) (0 assignees)Rust (6 forks)auto 404
P1awaiting-responsebackendbugenhancementgood first issueperformanceplatform/linuxqasafety

Repository metrics

Stars
 (35 stars)
PR merge metrics
 (No merged PRs in 30d)

Description

[agent]

Agent: Claude Code (claude-sonnet-4-6) — caro-qa-agent


Problem

caro ai --once "<prompt>" hangs silently with zero output on both stdout and stderr when no model has been downloaded. The command shows no spinner, no progress indicator, no "downloading model" message, and no error — it simply freezes until a timeout kills it. A user invoking caro ai --once for the first time has no way to tell whether the program is working, stuck, or broken. In practice, they will hit Ctrl-C and conclude the feature is non-functional.

This is distinct from FLAKE-001 (model download blocked in sandbox). Even when the download eventually succeeds, the user sees nothing during the wait. The main caro -p "..." --dry-run path at least shows the telemetry consent prompt before reaching model initialization; caro ai --once bypasses telemetry entirely and provides zero feedback.

Reproduction

# Build from source (no pre-downloaded model)
cargo build --release --features embedded-cpu

# Redirect both streams to prove silence:
./target/release/caro ai --once "list files in current directory" \
  > /tmp/ai_stdout.txt 2> /tmp/ai_stderr.txt &
PID=$!
sleep 90
kill $PID 2>/dev/null

echo "stdout bytes: $(wc -c < /tmp/ai_stdout.txt)"
echo "stderr bytes: $(wc -c < /tmp/ai_stderr.txt)"
# → stdout bytes: 0
# → stderr bytes: 0

Tested with timeout values of 15s, 30s, and 90s — all produced empty stdout and stderr.

Expected vs Actual

Expected: A spinner or at minimum a one-line message on stderr ("Initializing backend…", "Downloading model…", or equivalent) within the first 2 seconds of invocation, so the user knows the command is running.

Actual: Complete silence for the entire duration of model initialization (90+ seconds in a sandbox with a slow/blocked download). No output whatsoever on stdout or stderr. Exit code 124 (timeout) when killed externally.

Environment

  • caro version: caro 1.5.0 (be07b22 2026-07-18)
  • OS: Linux 6.18.5-fc-v20 x86_64 (remote sandbox)
  • Test date: 2026-08-15
  • Backend: embedded (auto-detected; no model pre-downloaded)

Investigation

The caro ai --once command dispatches early in main() before telemetry initialization (src/main.rs:3256–3271), calling run_ai_once() at src/main.rs:1072.

Inside run_ai_once(), the first blocking operation is:

// src/main.rs:1100–1108
let cli_app = caro::cli::CliApp::with_overrides(
    caro::cli::CliConfig::default(),
    cli.backend.clone(),
    cli.model_name.clone(),
    cli.force_llm,
    cli.advisor.clone(),
)
.await                                          // ← hangs here
.map_err(|e| format!("initializing backend: {}", e))?;

There is no spinner, progress message, or timeout wrapper around this .await. CliApp::with_overrides initializes the embedded backend, which triggers model download on a cold start. The main command path wraps its equivalent initialization in a spinner and shows the telemetry prompt first; run_ai_once has neither.

The safety unit tests (34/34 passed) and --help output for ai are both healthy. The hang is isolated to the backend-initialization phase of run_ai_once.

Severity

P1 — The advertised --once flag is documented as "the only mode supported today" in caro ai --help. A user invoking this mode on first run sees nothing happen. There is no error, no progress, and no indication that work is occurring. The feature appears completely non-functional even when it would eventually succeed.


caro QA agent — daily rotation slot A+B+C, scheduled remote run 2026-08-15

Contributor guide