What causes "tinyagents harness run failed: {e}" in tinyhumansai/openhuman?

Enable debug/trace logging and grep for [tinyagents] — the re-surfacing branch and middlewares emit diagnostics before this line

tinyhumansai/openhuman · error

tinyagents harness run failed: {e}

Error message

tinyagents harness run failed: {e}

What it means

Terminal wrapper when the tinyagents harness drive future returns Err and the shared error_slot is empty (mod.rs:981). Provider-shaped failures are intercepted just above and re-surfaced as the original typed provider error (#4457 defect B), so this message covers non-provider failures: middleware errors, graph errors, internal harness faults. The {e} chain is the actual cause.

Source

Thrown at src/openhuman/agent/tinyagents/mod.rs:981

            // Otherwise prefer the original typed provider error (preserves
            // `AgentError` downcasts the caller relies on) over the harness's
            // string wrap — this is where a genuine model/provider failure that
            // halted the run is re-surfaced with its real classification.
            // #4469 item 3: `into_inner` recovers a poisoned slot so a panic in
            // one run can't cascade into a second panic here that would mask the
            // original typed provider error.
            if let Some(original) = error_slot
                .lock()
                .unwrap_or_else(std::sync::PoisonError::into_inner)
                .take()
            {
                tracing::debug!(
                    model,
                    "[tinyagents] re-surfacing typed provider error from error_slot as the run failure — #4457 defect B"
                );
                return Err(original);
            }
            return Err(anyhow::anyhow!("tinyagents harness run failed: {e}"));
        }
    };
    // Durable journal: the harness returned a transcript, so stamp the terminal
    // completed status (best-effort, non-fatal). The event stream carries no
    // run-terminal event, so this caller-driven write is authoritative.
    if let Some(journal) = &turn_journal {
        journal.finish_completed().await;
    }
    // Context-compression provenance (issue #4249, 03.1 item 6): the harness's
    // `AgentEvent::Compressed` projection only carries token deltas, so drain the
    // compression middleware's `records()` here — each carries the full
    // `CompressionProvenance` (source ids + before/after token estimates + policy
    // reason) built by `ModelSummarizer`. Surfaced at info with a
    // grep-friendly `[context]` prefix so every compaction is auditable, not just
    // its net token saving.
    if let Some(mw) = &compression_mw {
        let records = mw.records();
        if !records.is_empty() {

View on GitHub (pinned to a221052e0d)

Solutions

Enable debug/trace logging and grep for [tinyagents] — the re-surfacing branch and middlewares emit diagnostics before this line
Inspect the turn journal / AgentEvent stream for the last event before the failure to identify the failing stage
Re-run with the same inputs to separate transient (provider/network — usually surfaced via error_slot instead) from deterministic (middleware bug) causes
If deterministic, capture {e:#} (full chain) plus the run_id and file an issue

Defensive patterns

Strategy: try-catch

Try / catch

// Keep the full cause chain and persist a terminal status so replay sees it
let outcome = run_turn_harness(assembled).await;
if let Err(e) = outcome {
    tracing::error!("[turn] harness run failed: {e:#}");
    journal.finish_failed(&e.to_string()).await;
    return Err(e);
}

Prevention

Run with [tinyagents] debug/trace enabled during harness middleware development
Prefer typed provider errors via the error_slot pattern so provider failures keep their classification
Journal turn events so the last event before a failure identifies the stage

When it happens

Trigger: A middleware in the assembled turn harness returning Err (context compression, journalling, event bridge); TinyAgentsError::Graph step failures inside the harness run; a newly added middleware that errors on specific event shapes; panics caught and converted to errors by the harness.

Common situations: Right after adding or upgrading harness middleware; failures that only reproduce mid-turn (after model calls started); sparse logs because the typed-error slot path never triggered.

Related errors

AI-assisted analysis of tinyhumansai/openhuman@a221052e0d (2026-08-16). Data as JSON: /api/errors/a075ccd1e6ac0a9f. Report an issue: GitHub.