You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Fast failure on network errors and concise error output #39771
Problem A - No short timeout for network ops, no fallback
When the network is flaky (common in China where GitHub HTTPS is often blocked but SSH works fine), the tool sits there for the default 60-120s timeout. No fast failure, no fallback.
Problem B - Error output is way too verbose
When something fails, the tool dumps full stack traces and re-analysis. Every CI cycle is ~5000 tokens of noise.
No issue template was used. Please resubmit using one of the three required templates: Bug Report, Feature Request (title must start with [FEATURE]:), or Question. Bug reports require a Description field with reproduction steps and system/environment information. Feature requests require a verification checkbox and a description of the problem or need.
This issue combines two separate concerns (network timeout behavior and error output verbosity) — consider splitting them into separate issues using the appropriate templates.
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
changed the title [-]No fast failure on network errors, verbose output wastes tokens[/-][+][FEATURE]: Fast failure on network errors and concise error output[/+]on Jul 31, 2026
Thanks for updating the issue! It now follows the contributing guidelines and looks good. We appreciate the clear problem description and proposed solution.
I reviewed the potential duplicates mentioned by the bot.
#35090 (server-side network resilience) — That issue is about making the Desktop/Server architecture survive restricted networks. This issue is about client-side UX: the shell tool hanging for 60-120s before failing. Different layer, different fix.
#30611 (automatic retry on transient errors) — That issue proposes retrying automatically when network errors occur. This one proposes the opposite: fast failure when the network is clearly unreachable. The two are complementary — do a quick pre-flight check first (e.g. \curl --connect-timeout 3); if the probe fails, fast-fail immediately; if the probe succeeds but the actual request fails, then retry. But right now there is no probe, just a blind 60-120s wait.
Activity
github-actions commentedon Jul 30, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
[FEATURE]:), or Question. Bug reports require a Description field with reproduction steps and system/environment information. Feature requests require a verification checkbox and a description of the problem or need.Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
ETIMEDOUT,ENOTFOUND, flaky connections)If you believe this was flagged incorrectly, please let a maintainer know.
[-]No fast failure on network errors, verbose output wastes tokens[/-][+][FEATURE]: Fast failure on network errors and concise error output[/+]github-actions commentedon Jul 31, 2026
Thanks for updating the issue! It now follows the contributing guidelines and looks good. We appreciate the clear problem description and proposed solution.
openchat-ai commentedon Jul 31, 2026
I reviewed the potential duplicates mentioned by the bot.
#35090 (server-side network resilience) — That issue is about making the Desktop/Server architecture survive restricted networks. This issue is about client-side UX: the shell tool hanging for 60-120s before failing. Different layer, different fix.
#30611 (automatic retry on transient errors) — That issue proposes retrying automatically when network errors occur. This one proposes the opposite: fast failure when the network is clearly unreachable. The two are complementary — do a quick pre-flight check first (e.g. \curl --connect-timeout 3); if the probe fails, fast-fail immediately; if the probe succeeds but the actual request fails, then retry. But right now there is no probe, just a blind 60-120s wait.
I don't think either is a true duplicate.
github-actions commentedon Sep 29, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.