Skip to content

fix(core): report completed run status from RUN lifecycle#176

Open
abhay-codes07 wants to merge 1 commit into
rajudandigam:mainfrom
abhay-codes07:fix/explain-run-status
Open

fix(core): report completed run status from RUN lifecycle#176
abhay-codes07 wants to merge 1 commit into
rajudandigam:mainfrom
abhay-codes07:fix/explain-run-status

Conversation

@abhay-codes07

Copy link
Copy Markdown
Contributor

Summary

Fixes #173: explain reported run.status: "running" for a run that had already completed successfully, while list and view showed success for the same run.

Root cause is in TreeBuilder.computeRunStatus (packages/core/src/logs/tree-builder.ts), which explain reaches through openTrace. It returned "running" whenever any event carried a "running" status. The v0.1 to persisted bridge (from-trace-event.ts) writes each node as a started event (status "running") followed by a completed event, so a finished run still contains "running" started rows and the whole run was reported as running. list/view go through extractMetadata/buildRunSummary, which read the RUN completion status, so they were already correct.

Changes:

  • computeRunStatus now derives the run status from the RUN node lifecycle, matching manualTraceEventsToRunTree and extractMetadata: a run is "running" only until its RUN completion event is present, then it takes that terminal status (ok/error). Traces with no RUN node (log-only ingestion) keep the previous any-error / any-running fallback. This also lets completed runs read through openTrace populate endedAt/durationMs, which were previously suppressed because the status was stuck at "running".
  • explain now maps the run-tree status vocabulary (ok/error/running) to the user-facing success/error/running vocabulary that list/view/stats use, so the command output and the run.status fact agree with the sibling commands.

How I verified

Repro from the issue, before vs after:

list:          success (unchanged)
view:          Status: success (unchanged)
explain human: Status: running  ->  Status: success
explain --json status:  "running"  ->  "success"
explain run.status fact: "running"  ->  "success"

Type of change

  • Bug fix (non-breaking)
  • Documentation only
  • Example / recipe / fixture
  • Feature or enhancement (scoped)
  • Breaking change (requires major version plan)

Product boundaries

  • Local-first only, no network upload added
  • No new vendor sinks
  • No SaaS / dashboard scope added
  • schemaVersion "0.1" manual traces remain compatible
  • No step_failed event introduced
  • inspectRun default tracing behavior unchanged

Packages touched

  • @agent-inspect/core
  • @agent-inspect/cli (test only)

Validation

pnpm typecheck  # pass
pnpm --filter @agent-inspect/core test -- tree-bridge tree-builder  # 17 pass
pnpm --filter @agent-inspect/cli test -- explain  # 6 pass

Checklist

  • Tests added or updated (tree-bridge status cases + explain success assertion)
  • Docs updated (n/a, internal status derivation)
  • No new runtime dependencies
  • No version bump in this PR
  • No secrets, production logs, or real PII in commits

…lder

TreeBuilder.computeRunStatus returned "running" whenever any event
carried a "running" status. The v0.1 to persisted bridge writes each
node as a started event (status "running") followed by a completed
event, so a fully finished run still contained "running" started rows
and the whole run was reported as running. explain reads run trees
through openTrace and surfaced this as run.status "running" for a
completed run, while list and view (extractMetadata / buildRunSummary)
correctly showed success.

Derive the run status from the RUN node lifecycle instead, matching
manualTraceEventsToRunTree and extractMetadata: the run is running only
until its RUN completion event is present, then it takes that terminal
status. Traces with no RUN node keep the previous any-error / any-running
fallback.

Also normalize the explain status output to the user-facing vocabulary
(success/error/running) so explain agrees with list/view for the same
run, as the issue requests.

Fixes rajudandigam#173
Copilot AI review requested due to automatic review settings July 18, 2026 07:52

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@vercel

vercel Bot commented Jul 18, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
agent-inspect-website Skipped Skipped Jul 18, 2026 7:52am

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[bug] explain reports completed successful run as running

2 participants