plengauer / plengauer/claude-github-tools

github-generic: escalation ladder doesn't handle hung tool calls

Open
#36 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
0
Forks
0
Avg merge
3h 18m
Merged PRs (30d)
53

Description

Problem

The github-generic escalation ladder (GitHub MCP -> REST -> GraphQL -> Chrome -> computer control) assumes failure arrives as an error: something returns, it says what went wrong, and that's the cue to drop a tier.

A tool call that hangs and never returns is not an error. Nothing is raised, nothing is caught, the ladder never fires.

This showed up concretely: a four-minute timeout with no response body, no status code, and no reason, repeated identically across three MCP servers and three API surfaces. Six escalation steps burned ~40 minutes without producing a single actionable error. Without a rule for this, the natural behaviour is to retry the same call, because nothing has said it won't work. That is the trap.

Proposed rules to fold into the skill

1. A hang is a failure signal, same as an error

Treat "no result after the timeout" as a tier failure and escalate on it. Do not retry the identical call — a call that hung once will hang again, costing the full timeout each time for nothing.

Retry the same call only when something external has demonstrably changed (servers restarted, stuck approval dialog cleared, credentials altered). If the user asks for a repeat, comply once, but say plainly that it's a repeat of a call that already failed and that nothing observable has changed.

2. Verify against the remote before doing anything else

A hang does not tell you whether the write landed. The request may have reached GitHub and succeeded with the response lost on the way back.

After any hung write, read the remote state before retrying, reporting, or escalating:

  • File content: fetch raw.githubusercontent.com/OWNER/REPO/BRANCH/PATH with a cache-buster — free, and it doesn't touch the stuck path.
  • Refs, PRs, commits: any read tool. Reads kept working in every case observed.

Never report a write as failed, or retry it, on the strength of the timeout alone. Retrying a write that actually succeeded can duplicate commits or clobber newer state.

3. Probe to localize before escalating

Before spending four minutes per tier walking the ladder, spend one call narrowing down what is gated:

Probe Distinguishes
any read (get_content, list_commits) transport dead vs. writes gated
content-free write (gitcreate_ref — scratch branch) all writes gated vs. content writes gated
tiny content write (6-byte file, scratch branch) payload size vs. operation class
non-default branch target branch protection vs. everything else

In the incident this came from, that sequence localized the fault to creation of git objects (blobs and commits) specifically — every other variable eliminated. gitcreate_blob is the sharpest single probe: the smallest possible content-creating call, no commit, ref, or branch involved. If it hangs, every content route will hang and the remaining tiers aren't worth walking.

Probes also find what still works. Here, non-content writes kept working, so PR creation and auto-merge stayed reachable once content arrived by another path — worth knowing before declaring the task blocked.

4. Budget the wall clock, report early

Set a total budget for a stuck operation (~3 failed attempts or ~10 minutes, whichever comes first). On hitting it, stop and report: what was tried, what the probes established and ruled out, the verified remote state (landed / did not land), and the routes still open including manual ones.

A hung tool is usually an environment problem the user fixes in seconds — restart a server, clear a dialog, grant a permission — and cannot fix at all while the agent silently burns timeouts. Escalating to the human early is the cheap move, not the last resort.

5. Clean up and disclose probe artifacts

Probes create real things: scratch branches, test files. Track them, say what was created, remove them or ask. Prefer probes that are harmless if they do succeed — gitcreate_tree without a ref update creates a dangling object that changes nothing until something points at it.

Notes on confidence

  • The numbers in rule 4 (3 attempts, 10 minutes) are judgment calls calibrated to a four-minute timeout, not measured.
  • The probe table generalizes from a single incident. That sequence isolated this fault cleanly; whether these are the right four splits for other failure modes is untested. The underlying principle — one cheap call to narrow the hypothesis before four minutes per tier — holds regardless.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Locate the github-generic escalation ladder entry point in the skill; the issue names no source file or test. Read how tool failures and writes are currently handled, then verify completion by covering hung-call escalation, remote-state verification, cheap probes, a total time budget, and probe cleanup and disclosure.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, graphql, javascript
Domain
api, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.