github / github/github-mcp-server
push_files takes ~70s per call (both success and fast-fail cases)
- Vorherrschende Sprache
- Go
- Sterne
- 33k
- Forks
- 5k
- Ø Merge
- 2 T. 1 Std.
- Gemergte PRs (30 T.)
- 52
Beschreibung
### Describe the bug
`push_files` calls are consistently slow (~1m12s–1m13s) in our MCP flow, even when one call fails with authorization error and the next call succeeds with the same payload.
This suggests significant latency before/around final Git operations, not only at final commit update step.
### Affected version
Using hosted/remote GitHub MCP server, version: `github-mcp-server/remote-57ddf9ca0de2f61fc022ca3cff21efc81a65fc99` (observed on 2026-03-08 via `initialize -> serverInfo.version`)
### Steps to reproduce the behavior
1. Call `github.push_files` with a payload of 7 files (Twig templates + one larger `classes/Email.php`) to:
- repo: https://github.com/Sogl/grav-plugin-login
- branch: https://github.com/Sogl/grav-plugin-login/tree/feature/multipart-emails
2. First call result:
- Error: `failed to create tree: POST https://api.github.com/repos/Sogl/grav-plugin-login/git/trees: 403 Resource not accessible by personal access token []`
- Client timing: `Worked for 1m 12s`
3. Fix PAT permissions and call `github.push_files` again with the same payload.
4. Second call result:
- Success, ref updated to commit: https://github.com/Sogl/grav-plugin-login/commit/8be0cd10415515109476025379545999f52b87b0
- Client timing: `Worked for 1m 13s`
### Expected vs actual behavior
Expected:
- Latency in seconds for this payload size, or at least clear diagnostics if server-side queueing/throttling is involved.
Actual:
- Both failed and successful calls take ~70+ seconds with almost identical duration.
### Logs
First call (failed, ~1m12s):
- `failed to create tree: POST https://api.github.com/repos/Sogl/grav-plugin-login/git/trees: 403 Resource not accessible by personal access token []`
Second call (success, ~1m13s):
- `{"ref":"refs/heads/feature/multipart-emails", ... "sha":"8be0cd10415515109476025379545999f52b87b0"}`
Request payload was the same large `push_files` body in both calls (7 files, full file contents).
Beitragsleitfaden
Bewertung
Dieses Issue wurde noch nicht bewertet.