fix: tool-version-check.sh hangs — add timeout and hung-process detection#2932
fix: tool-version-check.sh hangs — add timeout and hung-process detection#2932marcusquinn merged 1 commit intomainfrom
Conversation
Closes #2920 get_installed_version() already had timeout_sec wrapping the --version call, but three issues remained: 1. timeout_sec used perl alarm as macOS fallback — SIGALRM doesn't kill child processes that trap or ignore signals (e.g., Node MCP servers like macos-automator-mcp). Replaced with background+kill approach that escalates SIGTERM -> SIGKILL. 2. The exit code from timeout_sec was swallowed by '|| true', making it impossible to distinguish 'command timed out' from 'command failed'. Now captures the exit code and returns 'timeout' (not 'unknown') when exit code is 124. 3. The hardcoded 5s timeout was too short for slow interpreters. Added VERSION_TIMEOUT=10 constant (matching the issue's 5-10s recommendation) alongside the existing PKG_QUERY_TIMEOUT=30 for remote queries. Also adds: - 'timeout' status in check_tool() with distinct icon and color - timeout tools shown in --quiet mode (they indicate broken tools) - Consistent exit code 124 across all timeout_sec code paths
Summary of ChangesHello, I'm Gemini Code Assist1! 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 reliability and user experience of the Highlights
Changelog
Activity
Using Gemini Code AssistThe 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
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 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
|
|
Warning Rate limit exceeded
⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request effectively addresses the issue of hanging processes during version checks by implementing a more robust timeout mechanism. The new timeout_sec function with its background process and kill fallback is a significant improvement over the previous perl alarm approach. The changes to handle and display the timeout status are also clear and user-friendly. I have one suggestion regarding error stream redirection to improve debuggability, in line with the repository's general guidelines.
| local _ver_rc=0 | ||
| # shellcheck disable=SC2086 | ||
| timeout_sec 5 "$cmd" $ver_flag >"$_ver_log" 2>/dev/null || true | ||
| timeout_sec "$VERSION_TIMEOUT" "$cmd" $ver_flag >"$_ver_log" 2>/dev/null || _ver_rc=$? |
There was a problem hiding this comment.
While this works, redirecting stderr to /dev/null can hide important error messages if a command fails for reasons other than hanging (e.g., permission issues, missing dependencies). This makes debugging difficult. The project's general rules advise against blanket error suppression.
To improve debuggability, consider removing 2>/dev/null and letting any error messages from the version command be printed.
| timeout_sec "$VERSION_TIMEOUT" "$cmd" $ver_flag >"$_ver_log" 2>/dev/null || _ver_rc=$? | |
| timeout_sec "$VERSION_TIMEOUT" "$cmd" $ver_flag >"$_ver_log" || _ver_rc=$? |
References
- In shell scripts, avoid blanket suppression of errors with '2>/dev/null' to ensure that authentication, syntax, or system issues remain visible for debugging.
1 participant
Summary
macos-automator-mcp --versionhung indefinitelytimeout_secexit code (124) to distinguish "command timed out" from "command failed" — returns"timeout"instead of"unknown"VERSION_TIMEOUT=10constant for local--versioncalls (separate fromPKG_QUERY_TIMEOUT=30for remote queries)timeoutstatus display with distinct icon (⏱) and red color in both console and JSON output--quietmode since they indicate broken toolsCloses #2920
Testing
Verified on macOS (no
timeout/gtimeoutavailable — exercises the background+kill fallback):gh --version→2.87.3(normal path works)not installed(unchanged)sleep 999(simulates hung process) →timeoutafter ~10s (new behaviour)