Missing pagination for get_issue_labels tool #9

New Issue

b3nw · 2025-07-11T15:36:30-05:00

b3nw commented

2025-07-11 15:36:30 -05:00

In operation/label/label.go, the get_issue_labels tool fetches labels for a specific issue but lacks pagination parameters. If an issue has more labels than the default page size of the Gitea API, the tool will only return the first page of labels, leading to incomplete data.

Recommendation:
Add page and pageSize parameters to the get_issue_labels tool to allow for proper pagination, consistent with other listing functions like list_repo_labels.

In `operation/label/label.go`, the `get_issue_labels` tool fetches labels for a specific issue but lacks pagination parameters. If an issue has more labels than the default page size of the Gitea API, the tool will only return the first page of labels, leading to incomplete data. **Recommendation:** Add `page` and `pageSize` parameters to the `get_issue_labels` tool to allow for proper pagination, consistent with other listing functions like `list_repo_labels`.

b3nw commented

2025-07-11 15:45:14 -05:00

Code Review Analysis: Issue Not Valid

After thorough analysis of the codebase patterns and API design, this issue is not valid for the following reasons:

1. Pattern Analysis - "Get" vs "List" Operations

The codebase follows a clear distinction:

"Get" operations (single entity or closely related items):

get_issue_by_index - NO pagination (gets one issue)
get_repo_label - NO pagination (gets one label by ID)
get_issue_labels - NO pagination (gets labels for ONE specific issue)

"List" operations (collection queries):

list_repo_issues - HAS pagination (queries across repository)
list_repo_labels - HAS pagination (queries across repository)
list_repo_milestones - HAS pagination (queries across repository)

2. Practical Usage Analysis

Most issues have 0-10 labels
Even heavily labeled issues rarely exceed 20-30 labels
The current implementation gets ALL labels for the specific issue, which is appropriate
Adding pagination complexity for such a rare edge case is unnecessary

3. API Design Consistency

The get_issue_labels operation follows the correct "get" pattern since it retrieves labels for a specific issue, not a general query across the repository.

4. Current Implementation

labels, _, err := gitea.Client().GetIssueLabels(owner, repo, int64(index), gitea_sdk.ListLabelsOptions{})

Uses empty ListLabelsOptions{} to get ALL labels for the issue, which is the correct behavior.

Conclusion

The current implementation is correct and follows established patterns. Pagination is unnecessary for get_issue_labels based on API design principles and practical usage patterns.

Status: Won't Fix - Working as intended

# Code Review Analysis: Issue Not Valid After thorough analysis of the codebase patterns and API design, this issue is **not valid** for the following reasons: ## 1. **Pattern Analysis - "Get" vs "List" Operations** The codebase follows a clear distinction: **"Get" operations** (single entity or closely related items): - `get_issue_by_index` - NO pagination (gets one issue) - `get_repo_label` - NO pagination (gets one label by ID) - `get_issue_labels` - NO pagination (gets labels for ONE specific issue) **"List" operations** (collection queries): - `list_repo_issues` - HAS pagination (queries across repository) - `list_repo_labels` - HAS pagination (queries across repository) - `list_repo_milestones` - HAS pagination (queries across repository) ## 2. **Practical Usage Analysis** - Most issues have 0-10 labels - Even heavily labeled issues rarely exceed 20-30 labels - The current implementation gets ALL labels for the specific issue, which is appropriate - Adding pagination complexity for such a rare edge case is unnecessary ## 3. **API Design Consistency** The `get_issue_labels` operation follows the correct "get" pattern since it retrieves labels for a specific issue, not a general query across the repository. ## 4. **Current Implementation** ```go labels, _, err := gitea.Client().GetIssueLabels(owner, repo, int64(index), gitea_sdk.ListLabelsOptions{}) ``` Uses empty `ListLabelsOptions{}` to get ALL labels for the issue, which is the correct behavior. ## Conclusion The current implementation is correct and follows established patterns. Pagination is unnecessary for `get_issue_labels` based on API design principles and practical usage patterns. **Status: Won't Fix - Working as intended**

b3nw closed this issue

2025-07-11 15:45:19 -05:00

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: b3nw/gitea-mcp#9