refactor(runtime): propagate invoke SDK errors - #1937
Conversation
| }`, | ||
| { cause: error }, | ||
| ); | ||
| throw error; |
There was a problem hiding this comment.
Do these errors need to be wrapped with AgentCoreCLIError.fromError(error) with the relevant settings so we know the error was a service error?
There was a problem hiding this comment.
Good question. Headless failures are already converted through AgentCoreCLIError.fromError in the root catch, which recognizes ServiceException and assigns the appropriate error source. The TUI consumes the original exception directly for structured rendering, so I think wrapping it inside Core would duplicate that boundary.
be8f071 to
498aee6
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## refactor #1937 +/- ##
============================================
- Coverage 96.69% 96.68% -0.01%
============================================
Files 291 291
Lines 16012 15980 -32
============================================
- Hits 15483 15451 -32
Misses 529 529 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
498aee6 to
827d3b3
Compare
Summary
InvokeAgentRuntimeSDK failures without wrapping or rebuilding their diagnosticsServiceExceptionmetadata for structured TUI renderingFollow-up to the error-boundary review comments on #1930.
Testing
bun test src/core/core.test.ts src/handlers/runtime/invoke/invoke.screen.test.tsx src/handlers/runtime/invoke/invoke.test.tsx(85pass)bun run typecheckbun run lint:checkbun run format:checkbun test srcreached816pass; the only two failures were unchangedsrc/io/exec.test.tssubprocess-output assertions that reproduce in this environment