Skip to content

[FEATURE]: Fast failure on network errors and concise error output #39771

Closed as not planned

Description

@openchat-ai

Description

Two problems with shell command handling.

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.

Proposed Solution

  1. Smarter default timeouts: network ops 15s, build 300s, else 30s
  2. Quick network probe before API calls
  3. Error output: 1-2 line summary, full log to file

Verification

  • I have checked that this feature has not been suggested before

Activity

  1. github-actions commented on Jul 30, 2026

    @github-actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • 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:

    If you believe this was flagged incorrectly, please let a maintainer know.

  2. 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
  3. github-actions commented on Jul 31, 2026

    @github-actions
    Contributor

    Thanks for updating the issue! It now follows the contributing guidelines and looks good. We appreciate the clear problem description and proposed solution.

  4. openchat-ai commented on Jul 31, 2026

    @openchat-ai
    Author

    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.

  5. github-actions commented on Sep 29, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions