Repository navigation
LOU-U12: send a structured error to the model when a tool throws - #37
Merged
Merged
Conversation
When a tool's execute threw an ordinary error, the generic path set result: null, so the model saw the string "null" and could not tell the tool failed or why. The result is now { error: <error name>, toolName, message } (message only, never a stack, capped at 2,000 chars with a truncation marker), mirroring the LOU-U4 argument-validation shape. PropagatingToolError still aborts the run; events, onToolResult and postToolCall still see outcome.error. toolErrorMessage now falls back to String(error) for non-Error throws so those still count as errors. Docs: api-overview 'Argument validation' became 'Tool errors'.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
A thrown tool error now reaches the model as
{ error: <error name>, toolName, message }instead of the stringnull. Message only (no stack), capped at 2,000 chars with a... (truncated)marker.Why
The generic catch in
doExecuteToolCallsetresult: null, so the model could not tell a tool failed or why, and could not recover. Mirrors the LOU-U4 validation-error shape.How verified
npx tsc --noEmit: cleannpm run lint: 0 errors (442 pre-existing warnings, none added)npm run build+ create-loushy-agent build: successnpm run test:coverage: 89 files passed, exit 0npm run fallow: 0 above thresholdnpm run docs:verify-snippets: all 5 snippets type-check and run cleanlyNew tests (
src/execution/toolErrorResult.test.ts, scripted provider): structured error reaches the next request and the follow-up call succeeds; events/onToolResult/postToolCall still seeerror; truncation; non-Error throws;PropagatingToolErrorstill aborts.Notes for reviewer
outcome.errorstays the plain message string (events/hooks unchanged); the structured object is onlyoutcome.result. The original Error object is not newly exposed.toolErrorMessagenow falls back toString(error)for non-Error throws (previouslyundefined, which hid the error).{error, ...}family.{ error: message }; possible follow-up.🤖 Generated with Claude Code