fix(runtime): map failed terminal without error content to runtime_error by Astro-Han · Pull Request #63 · apache/maka

Astro-Han · 2026-06-19T08:58:43Z

Summary

Fresh-eye review of PR #62 (Codex P1 / Claude P3) found that the runtime_error classification only reached the AgentRunStore ledger, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures.

Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring error content. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first.

Fix: in failureFromTerminalEvent, when status='failed':

with error content reason/code → use that (e.g. 'tool_failed')
without error content → 'runtime_error' (not 'failed')

This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario.

Test plan

@maka/runtime 588/588 (updated locked test, +2 new: reason-code test, bare-failed-terminal test)
@maka/headless 93/93 (+1 end-to-end: ResultRecord.errorClass='runtime_error' for backend emitting only complete(stopReason=error))
npm run typecheck clean

Fresh-eye review (Codex P1 / Claude P3) found that PR #62 only fixed the AgentRunStore ledger failureClass, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures. Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring whether error content carried a precise reason. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first. Fix: in failureFromTerminalEvent, when status='failed': - with error content reason/code → use that (e.g. 'tool_failed') - without error content → 'runtime_error' (not 'failed') This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario. Tests: - runtime: updated locked test (failed+error content w/o reason → runtime_error), added reason-code test, added bare-failed-terminal test - headless: added end-to-end test verifying ResultRecord.errorClass='runtime_error' for a backend that emits only complete(stopReason=error)

Astro-Han · 2026-06-19T08:58:43Z

Summary

Fresh-eye review of PR #62 (Codex P1 / Claude P3) found that the runtime_error classification only reached the AgentRunStore ledger, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures.

Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring error content. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first.

Fix: in failureFromTerminalEvent, when status='failed':

with error content reason/code → use that (e.g. 'tool_failed')
without error content → 'runtime_error' (not 'failed')

This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario.

Test plan

@maka/runtime 588/588 (updated locked test, +2 new: reason-code test, bare-failed-terminal test)
@maka/headless 93/93 (+1 end-to-end: ResultRecord.errorClass='runtime_error' for backend emitting only complete(stopReason=error))
npm run typecheck clean

Fresh-eye review (Codex P1 / Claude P3) found that PR #62 only fixed the AgentRunStore ledger failureClass, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures. Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring whether error content carried a precise reason. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first. Fix: in failureFromTerminalEvent, when status='failed': - with error content reason/code → use that (e.g. 'tool_failed') - without error content → 'runtime_error' (not 'failed') This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario. Tests: - runtime: updated locked test (failed+error content w/o reason → runtime_error), added reason-code test, added bare-failed-terminal test - headless: added end-to-end test verifying ResultRecord.errorClass='runtime_error' for a backend that emits only complete(stopReason=error)

Astro-Han · 2026-06-19T08:58:43Z

Summary

Fresh-eye review of PR #62 (Codex P1 / Claude P3) found that the runtime_error classification only reached the AgentRunStore ledger, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures.

Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring error content. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first.

Fix: in failureFromTerminalEvent, when status='failed':

with error content reason/code → use that (e.g. 'tool_failed')
without error content → 'runtime_error' (not 'failed')

This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario.

Test plan

@maka/runtime 588/588 (updated locked test, +2 new: reason-code test, bare-failed-terminal test)
@maka/headless 93/93 (+1 end-to-end: ResultRecord.errorClass='runtime_error' for backend emitting only complete(stopReason=error))
npm run typecheck clean

Fresh-eye review (Codex P1 / Claude P3) found that PR #62 only fixed the AgentRunStore ledger failureClass, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures. Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring whether error content carried a precise reason. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first. Fix: in failureFromTerminalEvent, when status='failed': - with error content reason/code → use that (e.g. 'tool_failed') - without error content → 'runtime_error' (not 'failed') This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario. Tests: - runtime: updated locked test (failed+error content w/o reason → runtime_error), added reason-code test, added bare-failed-terminal test - headless: added end-to-end test verifying ResultRecord.errorClass='runtime_error' for a backend that emits only complete(stopReason=error)

Astro-Han · 2026-06-19T08:58:43Z

Summary

Fresh-eye review of PR #62 (Codex P1 / Claude P3) found that the runtime_error classification only reached the AgentRunStore ledger, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures.

Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring error content. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first.

Fix: in failureFromTerminalEvent, when status='failed':

with error content reason/code → use that (e.g. 'tool_failed')
without error content → 'runtime_error' (not 'failed')

This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario.

Test plan

@maka/runtime 588/588 (updated locked test, +2 new: reason-code test, bare-failed-terminal test)
@maka/headless 93/93 (+1 end-to-end: ResultRecord.errorClass='runtime_error' for backend emitting only complete(stopReason=error))
npm run typecheck clean

Fresh-eye review (Codex P1 / Claude P3) found that PR #62 only fixed the AgentRunStore ledger failureClass, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures. Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring whether error content carried a precise reason. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first. Fix: in failureFromTerminalEvent, when status='failed': - with error content reason/code → use that (e.g. 'tool_failed') - without error content → 'runtime_error' (not 'failed') This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario. Tests: - runtime: updated locked test (failed+error content w/o reason → runtime_error), added reason-code test, added bare-failed-terminal test - headless: added end-to-end test verifying ResultRecord.errorClass='runtime_error' for a backend that emits only complete(stopReason=error)

Astro-Han · 2026-06-19T08:58:43Z

Summary

Fresh-eye review of PR #62 (Codex P1 / Claude P3) found that the runtime_error classification only reached the AgentRunStore ledger, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures.

Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring error content. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first.

Fix: in failureFromTerminalEvent, when status='failed':

with error content reason/code → use that (e.g. 'tool_failed')
without error content → 'runtime_error' (not 'failed')

This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario.

Test plan

@maka/runtime 588/588 (updated locked test, +2 new: reason-code test, bare-failed-terminal test)
@maka/headless 93/93 (+1 end-to-end: ResultRecord.errorClass='runtime_error' for backend emitting only complete(stopReason=error))
npm run typecheck clean

Fresh-eye review (Codex P1 / Claude P3) found that PR #62 only fixed the AgentRunStore ledger failureClass, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures. Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring whether error content carried a precise reason. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first. Fix: in failureFromTerminalEvent, when status='failed': - with error content reason/code → use that (e.g. 'tool_failed') - without error content → 'runtime_error' (not 'failed') This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario. Tests: - runtime: updated locked test (failed+error content w/o reason → runtime_error), added reason-code test, added bare-failed-terminal test - headless: added end-to-end test verifying ResultRecord.errorClass='runtime_error' for a backend that emits only complete(stopReason=error)

Astro-Han · 2026-06-19T08:58:43Z

Summary

Fresh-eye review of PR #62 (Codex P1 / Claude P3) found that the runtime_error classification only reached the AgentRunStore ledger, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures.

Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring error content. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first.

Fix: in failureFromTerminalEvent, when status='failed':

with error content reason/code → use that (e.g. 'tool_failed')
without error content → 'runtime_error' (not 'failed')

This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario.

Test plan

@maka/runtime 588/588 (updated locked test, +2 new: reason-code test, bare-failed-terminal test)
@maka/headless 93/93 (+1 end-to-end: ResultRecord.errorClass='runtime_error' for backend emitting only complete(stopReason=error))
npm run typecheck clean

Fresh-eye review (Codex P1 / Claude P3) found that PR #62 only fixed the AgentRunStore ledger failureClass, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures. Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring whether error content carried a precise reason. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first. Fix: in failureFromTerminalEvent, when status='failed': - with error content reason/code → use that (e.g. 'tool_failed') - without error content → 'runtime_error' (not 'failed') This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario. Tests: - runtime: updated locked test (failed+error content w/o reason → runtime_error), added reason-code test, added bare-failed-terminal test - headless: added end-to-end test verifying ResultRecord.errorClass='runtime_error' for a backend that emits only complete(stopReason=error)

Astro-Han · 2026-06-19T08:58:43Z

Summary

Fresh-eye review of PR #62 (Codex P1 / Claude P3) found that the runtime_error classification only reached the AgentRunStore ledger, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures.

Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring error content. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first.

Fix: in failureFromTerminalEvent, when status='failed':

with error content reason/code → use that (e.g. 'tool_failed')
without error content → 'runtime_error' (not 'failed')

This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario.

Test plan

@maka/runtime 588/588 (updated locked test, +2 new: reason-code test, bare-failed-terminal test)
@maka/headless 93/93 (+1 end-to-end: ResultRecord.errorClass='runtime_error' for backend emitting only complete(stopReason=error))
npm run typecheck clean

Fresh-eye review (Codex P1 / Claude P3) found that PR #62 only fixed the AgentRunStore ledger failureClass, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures. Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring whether error content carried a precise reason. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first. Fix: in failureFromTerminalEvent, when status='failed': - with error content reason/code → use that (e.g. 'tool_failed') - without error content → 'runtime_error' (not 'failed') This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario. Tests: - runtime: updated locked test (failed+error content w/o reason → runtime_error), added reason-code test, added bare-failed-terminal test - headless: added end-to-end test verifying ResultRecord.errorClass='runtime_error' for a backend that emits only complete(stopReason=error)

Astro-Han · 2026-06-19T08:58:43Z

Summary

Fresh-eye review of PR #62 (Codex P1 / Claude P3) found that the runtime_error classification only reached the AgentRunStore ledger, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures.

Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring error content. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first.

Fix: in failureFromTerminalEvent, when status='failed':

with error content reason/code → use that (e.g. 'tool_failed')
without error content → 'runtime_error' (not 'failed')

This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario.

Test plan

@maka/runtime 588/588 (updated locked test, +2 new: reason-code test, bare-failed-terminal test)
@maka/headless 93/93 (+1 end-to-end: ResultRecord.errorClass='runtime_error' for backend emitting only complete(stopReason=error))
npm run typecheck clean

Fresh-eye review (Codex P1 / Claude P3) found that PR #62 only fixed the AgentRunStore ledger failureClass, not the InvocationResult.failure.class that benchmark ResultRecord reads. A complete(stopReason=error) with no preceding error event still surfaced as errorClass='failed' in ResultRecord — indistinguishable from other failures. Root cause: failureFromTerminalEvent returned class=status (i.e. 'failed') for any failed terminal, ignoring whether error content carried a precise reason. The error-content branch (which extracts content.reason) was unreachable for terminal events because the terminal check ran first. Fix: in failureFromTerminalEvent, when status='failed': - with error content reason/code → use that (e.g. 'tool_failed') - without error content → 'runtime_error' (not 'failed') This makes the invocation path consistent with the run ledger, so ResultRecord.errorClass reads 'runtime_error' for the bare-error scenario. Tests: - runtime: updated locked test (failed+error content w/o reason → runtime_error), added reason-code test, added bare-failed-terminal test - headless: added end-to-end test verifying ResultRecord.errorClass='runtime_error' for a backend that emits only complete(stopReason=error)

Astro-Han merged commit 9c904bb into mainJun 19, 2026