Centralize tool result error handling in format with error_line helper

[LasmarKhalifa]

No description provided.

[LasmarKhalifa]

• add task tool result formatter #963
• add agent tool result formatter #962
• add taskoutput tool result formatter backed by nokogiri #960
• add taskcreate tool result formatter #959
• add taskupdate tool result formatter #958
• add todowrite tool result formatter #957
• add skill tool result formatter #956
• add edit tool result formatter #955
• add write tool result formatter #954
• add grep tool result formatter #953
• add glob tool result formatter #952
• add read tool result formatter #951
• add bash tool result formatter #949
• Centralize tool result error handling in format with error_line helper #948 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[juniper-shopify]

Nice foundation PR! The error-handling centralization is clean — pulling the error path into an early-return at the top of format means every downstream formatter only needs to think about the success case. Makes the rest of your stack cleaner.

Two small things to address:

1. The error_line doc comment could use a couple of examples (see inline comment).
2. A test for error_line when content is nil would round out the edge-case coverage.

And lets switch to the xml parser we had talked about

[juniper-shopify]

The doc comment here is good — it explains what the method does. Since this is a foundation helper that every tool in the stack will rely on for error formatting, it would be helpful to expand it a bit:

# Renders "<TOOL> ERROR <message>" with any <tool_use_error> wrapper stripped.
#
# Reads the instance's +content+ and +tool_name+ to produce a single-line
# error summary. Error messages are intentionally NOT truncated so the full
# diagnostic is preserved for debugging.
#
# Examples:
#   BASH ERROR File has not been read yet.
#   UNKNOWN ERROR command not found
#
#: () -> String
def error_line

The reason is that someone reading a downstream formatter for the first time will look at error_line to understand the contract — having examples makes that a 5-second task instead of a 30-second one.

[juniper-shopify]

Nice coverage here. One edge case to add: what happens when content is nil? The implementation handles it via content.to_s, but an explicit test documents that expectation:

test "error_line handles nil content gracefully" do
  tool_use_message = Claude::Messages::ToolUseMessage.new(
    type: :tool_use,
    hash: { name: "read", input: {} },
  )
  tool_result = Claude::ToolResult.new(
    tool_use: tool_use_message,
    content: nil,
    is_error: true,
  )

  output = tool_result.send(:error_line)

  assert_equal "READ ERROR", output
end

Something to think about: when content is nil, this produces "READ ERROR " (with a trailing space) because the string interpolation gives "READ ERROR #{""}". If you'd prefer "READ ERROR" with no trailing space, a .strip or .squeeze(" ") at the end would do it — but it's a very minor cosmetic point.

[juniper-shopify]

as we had previously discussed, let's parse this with an xml parser