Canary build: Goose does not handle tool error response

[apeatling]

Describe the bug
When tool a returns an error and the request times out I get:

  2025-02-13T18:09:02.673465Z ERROR goose::agents::truncate: Error: Request failed: Request failed with status: 400 Bad Request. Message: messages.5: Messages containing `tool_use` blocks must be followed by a user message with `tool_result` blocks
    at crates/goose/src/agents/truncate.rs:279

It's unclear to me if this is a specific implementation issue with the Github MCP server from Anthropic, or the way that Goose is handling the error response and initiating a retry or adjustment to recover and fix the tool call parameters. If this error occurs, the entire session continues to show the error and Goose can't recover from it.

Here is the error in the conversation, notice the timeout:

─── create_pull_request_review | github ──────────────────────────
body: ...
comments:
    -
        body: ...
        diff_hunk: ...
        path: src/hooks/use-build-site.js
        position: 53
    -
        body: ...
        diff_hunk: ...
        path: src/utils/colors.js
        position: 47
    -
        body: ...
        diff_hunk: ...
        path: src/components/assembler-debug/index.js
        position: 362
event: COMMENT
owner: ...
pull_number: 2290
repo: ...


Execution failed: Call to 'github-mcp-server' failed for 'tools/call'. Error from mcp-server: request timed out

◓  Evolving ethereal entities...                                                                                                                                                     2025-02-13T18:09:02.673465Z ERROR goose::agents::truncate: Error: Request failed: Request failed with status: 400 Bad Request. Message: messages.5: Messages containing `tool_use` blocks must be followed by a user message with `tool_result` blocks
    at crates/goose/src/agents/truncate.rs:279

Ran into this error: Request failed: Request failed with status: 400 Bad Request. Message: messages.5: Messages containing `tool_use` blocks must be followed by a user message wit
h `tool_result` blocks.

Please retry if you think this is a transient or recoverable error.

This is what I see in the logs, notice that the GitHub API is telling me the data in the request is not correct, and it throws an error, but Goose does not seem to respond to this:

  2025-02-13T18:04:02.469780Z DEBUG mcp_client::transport::stdio: Sending outgoing message, Request(JsonRpcRequest { jsonrpc: "2.0", id: Some(5), method: "tools/call", params: Some(Object {"arguments": Object {"body": String("> [!NOTE] \n> This is an AI-generated review.\n\n@mdawaffe Thanks for working on improving the cover image color handling! The approach to store theme colors in a ref and pass them explicitly through the application makes sense to maintain consistent color usage across async operations. The shift to using CSS color names instead of hex values for AI prompts is a nice improvement too.\n\nThe implementation looks solid overall, and I appreciate the comprehensive test coverage. I've left a few inline comments about potential improvements and suggestions."), "comments": Array [Object {"body": String("Consider extracting the color ref pattern into a custom hook like `useCurrentThemeColors` since it's being used in multiple places. This would help reduce duplication and make the pattern more maintainable."), "diff_hunk": String("@@ -50,9 +51,12 @@ export default function useBuildSite() {\n \tconst { setCategories } = usePageMetadata();\n \tconst { setIsHandoff } = useDispatch( aiStore );\n \n-\tconst { saveStylesEntityRecord, setStyles } = useStyles();\n+\tconst { saveStylesEntityRecord, setStyles, getThemeColors } = useStyles();\n \tconst { createPage } = usePages();\n \n+\tconst themeColorsRef = useRef( null );\n+\tthemeColorsRef.current = getThemeColors();\n+"), "path": String("src/hooks/use-build-site.js"), "position": Number(53)}, Object {"body": String("You might want to consider adding JSDoc comments for this function to document the return type and parameters. Something like:\n```js\n/**\n * Convert a hex color to its CSS and generic color names\n * @param {string} hex - The hex color to convert (e.g. '#FF0000')\n * @returns {{css: string, generic: string}} Object containing the CSS color name and generic color name\n */\n```"), "diff_hunk": String("@@ -0,0 +1,50 @@\n+/**\n+ * External dependencies\n+ */\n+import { colord, extend } from 'colord';\n+import namesPlugin from 'colord/plugins/names';\n+extend( [ namesPlugin ] );\n+\n+const cssKeywordToColorMapping = {\n+\tbeige: 'white',\n+\tblack: 'black',\n+\tbisque: 'white',\n+\tblanchedalmond: 'white',\n+\tcrimson: 'red',\n+\tdarkslategray: 'black',\n+\tdarkgoldenrod: 'brown',\n+\tdarkolivegreen: 'green',\n+\tfirebrick: 'red',\n+\tgainsboro: 'gray',\n+\tgold: 'yellow',\n+\thoneydew: 'white',\n+\tindigo: 'blue',\n+\tivory: 'white',\n+\tkhaki: 'brown',\n+\tlavender: 'purple',\n+\tlavenderblush: 'white',\n+\tlightgrey: 'gray',\n+\tlightsalmon: 'orange',\n+\tlime: 'green',\n+\tlinen: 'white',\n+\tmaroon: 'red',\n+\tmintcream: 'white',\n+\tperu: 'brown',\n+\tsalmon: 'orange',\n+\tseashell: 'white',\n+\tsienna: 'brown',\n+\tsilver: 'gray',\n+\tsnow: 'white',\n+\ttan: 'brown',\n+\tteal: 'blue',\n+\ttomato: 'red',\n+\tviolet: 'purple',\n+\twheat: 'brown',\n+\twhite: 'white',\n+};\n+\n+export function colorNamesFromHex( hex ) {"), "path": String("src/utils/colors.js"), "position": Number(47)}, Object {"body": String("Consider using a React.memo here since Palette is rendering potentially expensive color swatches. This would help prevent unnecessary re-renders when parent components update but the colors haven't changed."), "diff_hunk": String("@@ -336,15 +337,33 @@ function UsageRow( { usageType, usage } ) {\n }\n \n function Palette( { paletteColors } ) {\n+\tconst copyColors = () => {\n+\t\tconst colors = paletteColors\n+\t\t\t.map( ( colorData ) => colorData.color || colorData )\n+\t\t\t.join( ', ' );\n+\t\twindow.navigator.clipboard.writeText( colors );\n+\t};\n+\n \treturn (\n \t\t<>\n-\t\t\t{ paletteColors.map( ( { color, slug } ) => (\n-\t\t\t\t<span\n-\t\t\t\t\tclassName=\"big-sky__ai-debug__swatch\"\n-\t\t\t\t\tkey={ slug }\n-\t\t\t\t\tstyle={ { backgroundColor: color } }\n-\t\t\t\t></span>\n-\t\t\t) ) }"), "path": String("src/components/assembler-debug/index.js"), "position": Number(362)}], "event": String("COMMENT"), "owner": String("..."), "pull_number": Number(...), "repo": String("...")}, "name": String("create_pull_request_review")}) })
    at crates/mcp-client/src/transport/stdio.rs:122

  2025-02-13T18:04:03.645255Z DEBUG mcp_client::transport::stdio: Received incoming message, Error(JsonRpcError { jsonrpc: "2.0", id: Some(5), error: ErrorData { code: -32603, message: "Validation Error: Unprocessable Entity\nDetails: {\"message\":\"Unprocessable Entity\",\"errors\":[\"Pull request review thread position is invalid and Pull request review thread diff hunk can't be blank\"],\"documentation_url\":\"https://docs.github.com/rest/pulls/reviews#create-a-review-for-a-pull-request\",\"status\":\"422\"}", data: None } })
    at crates/mcp-client/src/transport/stdio.rs:85

Please provide following information:

• OS & Arch: Mac OS 15.3.1
• Interface: CLI
• Version: Canary build as of this morning
• Extensions enabled: Github (anthropic), Slack (anthropic), Memory, developer
• Provider & Model: Claude Sonnet 3.5 latest

Additional context
Happy to provide any additional context.

[apeatling]

My expectation would be that Goose would see that the tool threw the error, use that as context to tell the model what the error was and retry the request with updates.

[apeatling]

For anyone encountering the same issues:

The problem is the way the Github MCP server throws errors:

throw new Error("Arguments are required");

This is not a recoverable error, it will cause Goose to time out waiting for a proper tool response.

return {
        content: [{ type: "text", text: JSON.stringify({
          message: "Arguments are required",
          code: "MISSING_ARGS",
          recoverable: false,
          suggestions: ["Please provide the required arguments for this tool"]
        }, null, 2) }],
        isError: true
      };

Returning a tool response that Goose can understand as an error it needs to recover from will fix the issue.

Ultimately I think goose needs to handle generic errors better, for example when using this Github MCP server in Cursor, it recovers fine with basic errors thrown.