fix: reliable network tests and improved tool error messages

[zmanian]

Summary

• Use RFC 5737 TEST-NET-1 IPs (192.0.2.1) instead of localhost for network failure tests, fixing flakiness behind HTTP proxies (closes fix: make network tests reliable with HTTP proxies #444, takeover from @hobostay)
• Format tool errors as Tool '<name>' failed: <reason> instead of bare Error: <reason> so the LLM can identify which tool failed and try alternatives. Does not short-circuit the agent loop. (closes bug: agent returns raw "[Called tool ...]" text when all tool call attempts fail #487, takeover from @lustsazeus-lab PR fix: generate user-friendly error message when all tool calls fail #530)

Test plan

• test_search_returns_error_on_network_failure passes with tightened assertion (no error.contains("error") tautology)
• health_with_unreachable_url_is_false uses TEST-NET-1
• test_tool_error_format_includes_tool_name regression test for error format
• cargo clippy --all --all-features clean

Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly enhances the system's stability and diagnostic capabilities. It improves the reliability of network-related tests by using dedicated test IP ranges, making them more consistent across diverse network environments. Additionally, it refines how tool errors are reported, providing more actionable information to the agent and facilitating better decision-making. A specific fix for WASM compilation caching on Windows also prevents potential file locking conflicts, contributing to overall system robustness.

Highlights

• Network Test Reliability: Switched network failure tests from localhost to RFC 5737 TEST-NET-1 IPs (192.0.2.1) to prevent flakiness behind HTTP proxies, resolving issue fix: make network tests reliable with HTTP proxies #444.
• Improved Tool Error Messages: Modified tool error messages to include the tool's name (e.g., "Tool '' failed: ") for better identification by the LLM, addressing issue bug: agent returns raw "[Called tool ...]" text when all tool call attempts fail #487.
• WASM Compilation Cache on Windows: Implemented a platform-aware WASM compilation cache mechanism to avoid file locking issues (OS error 33) on Windows when multiple engines share the default cache, resolving issue setting telegram bot error #448.

Changelog

• src/agent/dispatcher.rs
  • Updated the format of tool error messages to include the tool's name.
  • Added a new regression test to verify the improved tool error message format.
• src/channels/wasm/runtime.rs
  • Refactored the WASM compilation cache enabling logic to use a new, platform-aware enable_compilation_cache function, specifically addressing Windows-related file locking issues.
• src/sandbox/container.rs
  • Conditionally compiled the PathBuf import for Unix systems only.
• src/secrets/keychain.rs
  • Applied conditional compilation (#[cfg(any(target_os = "macos", target_os = "linux"))]) to SERVICE_NAME, MASTER_KEY_ACCOUNT constants, and the hex_to_bytes function, limiting their availability to macOS and Linux (and tests for hex_to_bytes).
• src/setup/channels.rs
  • Added #[allow(unused_mut)] attribute to the conflicts vector in detect_existing_cloudflared function.
• src/skills/catalog.rs
  • Modified the test_search_returns_error_on_network_failure test to use a TEST-NET-1 IP for more reliable network failure simulation.
  • Broadened the assertion for expected error messages to include various connection and gateway errors.
• src/tools/wasm/mod.rs
  • Exported the newly introduced enable_compilation_cache function from the runtime module.
• src/tools/wasm/runtime.rs
  • Introduced a new public function enable_compilation_cache to handle WASM compilation cache configuration, with special handling for Windows to prevent file locking issues by creating per-engine cache directories.
  • Updated the WasmToolRuntime initialization to utilize this new enable_compilation_cache function.
  • Added two new tests (test_enable_compilation_cache_with_explicit_dir and test_enable_compilation_cache_label_isolation) to verify the correct behavior and isolation of the compilation cache.
  • Changed PathBuf import to Path, PathBuf.
• src/tunnel/custom.rs
  • Updated the health_with_unreachable_url_is_false test to use a TEST-NET-1 IP for the unreachable URL, improving test reliability.
  • Added an explicit assertion message to the health check test.

Ignored Files

• Ignored by pattern: .github/workflows/** (2)
  • .github/workflows/code_style.yml
  • .github/workflows/test.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces two main improvements: making network failure tests more reliable by using TEST-NET-1 IPs, and enhancing tool error messages to include the tool name for better debugging by the LLM. The changes are well-implemented and include corresponding tests. I've provided a suggestion to further improve the error message formatting for better maintainability and effectiveness.

_{Note: Security Review did not run due to the size of the PR.}

[gemini-code-assist]

The new error message format introduces redundancy. The e.to_string() call for a ToolError often produces a string that already includes the tool's name (e.g., Tool http execution failed: ...). Prepended with Tool '{}' failed: , this results in a verbose and repetitive message like Tool 'http' failed: Tool error: Tool http execution failed: connection refused, which could be confusing for the LLM. To make the error message clearer and more concise, consider extracting just the core reason from the error.

                                    Err(e) => {
                                        let reason = match e {
                                            crate::error::Error::Tool(
                                                crate::error::ToolError::ExecutionFailed { reason, .. },
                                            ) => reason,
                                            other => other.to_string(),
                                        };
                                        format!("Tool '{}' failed: {}", tc.name, reason)
                                    },

References

1. Create specific error variants for different failure modes to provide semantically correct and clear error messages. This comment aims to improve the clarity and conciseness of error messages, aligning with the goal of providing semantically correct and clear error messages.