plengauer / plengauer/claude-github-tools
github-generic: escalation ladder doesn't handle hung tool calls
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/PATHwith 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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