Hiddenden/AegisGitea-MCP
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Issue-specific tools fail with -32603 Internal server error while repo-level tools work #27

New Issue
Closed
opened 2026-06-25 12:39:54 +00:00 by Latte · 1 comment
Latte commented 2026-06-25 12:39:54 +00:00
Owner
Copy Link
Copy Source

Title: Issue-specific tools fail with -32603 Internal server error while repo-level tools work

Summary

All tools that target a single issue by index return MCP error -32603: Internal server error, while repo-level list tools against the same repo succeed. This makes it impossible to read, comment on, or update any individual issue.

Affected tools (all fail)

  • get_issue
  • list_issue_comments
  • create_issue_comment

(Anything keyed on a specific issue index appears affected.)

Working tools (same repo, same session)

  • list_issues — returns the full issue list correctly

Reproduction

Repo: den-ops/infra (self-hosted Gitea at git.hiddenden.cafe)

  1. list_issues(owner="den-ops", repo="infra", state="open") → succeeds, returns 8 issues including #23.
  2. get_issue(owner="den-ops", repo="infra", index=23) → -32603 Internal server error
  3. list_issue_comments(owner="den-ops", repo="infra", index=23) → -32603 Internal server error
  4. create_issue_comment(owner="den-ops", repo="infra", index=23, body="...") → -32603 Internal server error

Reproduced consistently across ~5 calls; not transient. The repo-level call keeps working in between the failing per-issue calls, so connectivity and auth are fine.

Expected

get_issue / list_issue_comments return the issue/comments; create_issue_comment posts the comment.

Actual

JSON-RPC -32603 (Internal error) with no further detail returned to the client.

Environment

  • Gitea version: 1.26.2
  • Issue exists and is reachable via the web UI and via list_issues.

Notes / hypotheses

Since repo-level listing works but every index-keyed endpoint fails, the bug likely sits in the per-issue code path (e.g. how index is passed to the upstream Gitea API call, or response parsing of the single-issue payload) rather than in auth/transport. Server-side logs around the -32603 would pinpoint it.

**Title:** Issue-specific tools fail with `-32603 Internal server error` while repo-level tools work ## Summary All tools that target a single issue by index return `MCP error -32603: Internal server error`, while repo-level list tools against the same repo succeed. This makes it impossible to read, comment on, or update any individual issue. ## Affected tools (all fail) - `get_issue` - `list_issue_comments` - `create_issue_comment` (Anything keyed on a specific issue `index` appears affected.) ## Working tools (same repo, same session) - `list_issues` — returns the full issue list correctly ## Reproduction Repo: `den-ops/infra` (self-hosted Gitea at git.hiddenden.cafe) 1. `list_issues(owner="den-ops", repo="infra", state="open")` → succeeds, returns 8 issues including #23. 2. `get_issue(owner="den-ops", repo="infra", index=23)` → `-32603 Internal server error` 3. `list_issue_comments(owner="den-ops", repo="infra", index=23)` → `-32603 Internal server error` 4. `create_issue_comment(owner="den-ops", repo="infra", index=23, body="...")` → `-32603 Internal server error` Reproduced consistently across ~5 calls; not transient. The repo-level call keeps working in between the failing per-issue calls, so connectivity and auth are fine. ## Expected `get_issue` / `list_issue_comments` return the issue/comments; `create_issue_comment` posts the comment. ## Actual JSON-RPC `-32603` (Internal error) with no further detail returned to the client. ## Environment - Gitea version: 1.26.2 - Issue exists and is reachable via the web UI and via `list_issues`. ## Notes / hypotheses Since repo-level listing works but every index-keyed endpoint fails, the bug likely sits in the per-issue code path (e.g. how `index` is passed to the upstream Gitea API call, or response parsing of the single-issue payload) rather than in auth/transport. Server-side logs around the `-32603` would pinpoint it.
Bartender commented 2026-06-26 09:04:54 +00:00
Owner
Copy Link
Copy Source

Opgelost in 41749fd en bevestigd tegen de productie-image.

Verificatie

  • Oorspronkelijke repro (den-ops/infra #23): get_issue en list_issue_comments werken weer — geen -32603 meer.
  • create_issue_comment getest op een eigen test-issue + 25× in een write-loadtest.
  • Write-loadtest van ~100 parallelle, index-keyed calls (create/comment/label/close): 100% geslaagd, nul -32603 en geen rate-limiting.

Root-cause
get_issue crashte met 'NoneType' object is not iterable op issues waar Gitea labels/assignees als null of met non-dict elementen teruggaf (de #13-klasse), wat als opake JSON-RPC -32603 bij de client landde.

Fix

  • read_tools: non-dict label/assignee entries worden overgeslagen in get_issue_tool.
  • server: een ingepakte GiteaNotFoundError wordt nu via de __cause__-keten gedetecteerd en als 404 / -32000 met een duidelijke melding teruggegeven; gemaskeerde interne fouten bevatten nu het exception-type zodat toekomstige fouten diagnosticeerbaar zijn zonder messages/stacktraces te lekken.
  • Tests toegevoegd voor non-dict collection-elementen en de not-found / typed-error responses.

Sluiten.

Opgelost in `41749fd` en bevestigd tegen de productie-image. **Verificatie** - Oorspronkelijke repro (`den-ops/infra` #23): `get_issue` en `list_issue_comments` werken weer — geen `-32603` meer. - `create_issue_comment` getest op een eigen test-issue + 25× in een write-loadtest. - Write-loadtest van ~100 parallelle, index-keyed calls (create/comment/label/close): 100% geslaagd, nul `-32603` en geen rate-limiting. **Root-cause** `get_issue` crashte met `'NoneType' object is not iterable` op issues waar Gitea `labels`/`assignees` als `null` of met non-dict elementen teruggaf (de #13-klasse), wat als opake JSON-RPC `-32603` bij de client landde. **Fix** - `read_tools`: non-dict `label`/`assignee` entries worden overgeslagen in `get_issue_tool`. - `server`: een ingepakte `GiteaNotFoundError` wordt nu via de `__cause__`-keten gedetecteerd en als 404 / `-32000` met een duidelijke melding teruggegeven; gemaskeerde interne fouten bevatten nu het exception-type zodat toekomstige fouten diagnosticeerbaar zijn zonder messages/stacktraces te lekken. - Tests toegevoegd voor non-dict collection-elementen en de not-found / typed-error responses. Sluiten.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change, not backwards compatible
 Kind/Bug
Something is not working
 Kind/Chore
Maintenance, deps, CI/CD
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Refactor
Code restructuring, no behavior change
 Kind/Security
Security-related issue
 Priority/Critical
Must be addressed immediately
 Priority/High
Important, address soon
 Priority/Low
Nice to have
 Priority/Medium
Normal priority
 Reviewed/Confirmed
Issue has been confirmed
 Reviewed/Duplicate
Already tracked elsewhere
 Reviewed/Won't Fix
Acknowledged but won't be addressed
 Status/Blocked
Blocked by an external dependency
 Status/In Progress
Currently being worked on
 Status/Need More Info
Needs more information to proceed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Bartender (Bartender) Latte (Latte)
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Hiddenden/AegisGitea-MCP#27
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?