change the return to be object instead of array

[guitavano]

MCP protocol does not accept array

Summary by CodeRabbit

• Refactor
  • Standardized response structure across data loaders to consistently wrap returned data in a container object, improving API consistency and enabling more uniform response handling across the platform.

[coderabbitai]

Walkthrough

Systematically updates 21+ GitHub loader functions to wrap their return values in objects with a data property. Previously returning raw JSON or parsed arrays, they now return { data: <payload> }. Function signatures and request logic remain largely unchanged; only return value structures are modified.

Changes

Cohort / File(s)	Summary
Stats & Traffic Loaders github/loaders/getRepoStats... | github/loaders/getRepoTraffic...	Wraps parsed JSON responses in { data } objects instead of returning raw JSON directly.
Authenticated & Organization Loaders github/loaders/listAuthenticatedUserRepos.ts, github/loaders/listOrg(Members|OutsideCollaborators|Repos|Teams).ts	Wraps repository/member/team arrays and JSON in { data } wrapper objects. Changes return type signature from Promise<Type[]> to Promise<{ data: Type[] }>.
Repository Loaders github/loaders/listRepo(Branches|Collaborators|Commits|Contributors|Issues|Pulls|Teams|WorkflowRuns|Workflows).ts	Wraps parsed JSON responses and typed arrays in { data } objects. For listRepoIssues.ts, both single-issue and multi-issue paths now return wrapped data. Error paths unchanged.
Additional List Loaders github/loaders/listPublicGists.ts, github/loaders/listTeamMembers.ts, github/loaders/listWorkflowRunJobs.ts	Wraps parsed JSON and GistSimple[] arrays in { data } wrapper objects.
Search Loaders github/loaders/searchIssuesAndPRs.ts	Wraps parsed JSON response in { data } object instead of returning raw payload.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Repetitive pattern: All 21 files apply the same transformation (wrapping return values), reducing cognitive load per file.
• High file count: Despite homogeneity, 21 files require scanning for consistency and edge cases.
• Return type changes: Several files explicitly change type signatures (e.g., Promise<Repository[]> → Promise<{ data: Repository[] }>); verify all type updates align.
• Key areas to verify:
  • github/loaders/listRepoIssues.ts — Both success paths and error handling consistency
  • Files with explicit return type annotations — ensure TypeScript signatures match new wrapping structure
  • Callers of these loaders — inspect whether consuming code has been updated to access .data property

Possibly related issues

• [CLI]: Typings for Github -> List Issues is incomplete decocms/admin#730: Changes to listRepoIssues.ts wrapping return values as { data: GithubIssueClean[] } directly align with type signature modifications referenced in this issue.

Suggested reviewers

• mcandeia
• viktormarinho

Poem

🐰 Oh, what a bundling day of cheer!
Data wrapped in objects clear,
From raw to nested, structured tight,
Twenty loaders shining bright,
Each return now holds its prize—
Inside { data }, truth lies! ✨

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Description Check	⚠️ Warning	The pull request description is severely incomplete and does not follow the required template structure. The provided description contains only a single sentence ("MCP protocol does not accept array") and is missing all major required sections: no comprehensive explanation of the contribution, no issue link, no Loom video, and no demonstration link. While the brief statement provides minimal context about why the change was made, it falls far short of the template's requirements for a thorough pull request description.	The description must be expanded to follow the template structure: add a "What is this Contribution About?" section that thoroughly explains the changes across all 21 modified loaders, include an "Issue Link" section with the relevant issue number, provide a "Loom Video" section with a screencast demonstrating the changes, and add a "Demonstration Link" section pointing to a testable environment or branch. The current description needs to be substantially revised to meet the repository's contribution standards.
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The pull request title "change the return to be object instead of array" directly describes the primary change across the modifications: multiple GitHub loader functions are being updated to wrap their return values in an object with a data property instead of returning raw JSON responses or arrays. A developer scanning the repository history would understand that this change involves wrapping return values in objects. However, the title is somewhat generic and doesn't specify the scope (21 files affected) or the specific reason (MCP protocol compliance), which would provide more clarity about the changeset.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch tavano/fix-github-array-response

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

Tagging Options

Should a new tag be published when this PR is merged?

• 👍 for Patch 0.130.2 update
• 🎉 for Minor 0.131.0 update
• 🚀 for Major 1.0.0 update

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (4)

github/loaders/listOrgMembers.ts (1)

24-25: LGTM! Consider adding response validation.

The data wrapping is correctly implemented. As an optional future enhancement, consider validating response.ok or response.status before calling .json() to provide clearer error handling.

github/loaders/listRepoContributors.ts (1)

28-29: Approve with optional type annotation suggestion.

The wrapping pattern is correct and consistent with the PR objective.

For consistency with other loaders like listOrgRepos.ts, consider adding an explicit return type annotation:

 const loader = async (
   props: Props,
   _req: Request,
   ctx: AppContext,
-) => {
+): Promise<{ data: any }> => {

github/loaders/listRepoPulls.ts (1)

28-29: Approve with optional type annotation suggestion.

The return value is correctly wrapped in a data property.

Consider adding an explicit return type annotation for consistency:

 const loader = async (
   props: Props,
   _req: Request,
   ctx: AppContext,
-) => {
+): Promise<{ data: any }> => {

github/loaders/listRepoCollaborators.ts (1)

28-29: Approve with optional type annotation suggestion.

The wrapping logic is correct and aligns with the MCP protocol requirement.

Consider adding an explicit return type annotation:

 const loader = async (
   props: Props,
   _req: Request,
   ctx: AppContext,
-) => {
+): Promise<{ data: any }> => {

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 733d10d and b13ae2d.

📒 Files selected for processing (21)

• github/loaders/getRepoStatsCommitActivity.ts (1 hunks)
• github/loaders/getRepoTrafficPopularPaths.ts (1 hunks)
• github/loaders/getRepoTrafficPopularReferrers.ts (1 hunks)
• github/loaders/listAuthenticatedUserRepos.ts (1 hunks)
• github/loaders/listOrgMembers.ts (1 hunks)
• github/loaders/listOrgOutsideCollaborators.ts (1 hunks)
• github/loaders/listOrgRepos.ts (1 hunks)
• github/loaders/listOrgTeams.ts (1 hunks)
• github/loaders/listPublicGists.ts (1 hunks)
• github/loaders/listRepoBranches.ts (1 hunks)
• github/loaders/listRepoCollaborators.ts (1 hunks)
• github/loaders/listRepoCommits.ts (1 hunks)
• github/loaders/listRepoContributors.ts (1 hunks)
• github/loaders/listRepoIssues.ts (3 hunks)
• github/loaders/listRepoPulls.ts (1 hunks)
• github/loaders/listRepoTeams.ts (1 hunks)
• github/loaders/listRepoWorkflowRuns.ts (1 hunks)
• github/loaders/listRepoWorkflows.ts (1 hunks)
• github/loaders/listTeamMembers.ts (1 hunks)
• github/loaders/listWorkflowRunJobs.ts (1 hunks)
• github/loaders/searchIssuesAndPRs.ts (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (4)

github/loaders/listAuthenticatedUserRepos.ts (1)

github/utils/types.ts (1)

• Repository (22-33)

github/loaders/listPublicGists.ts (1)

github/utils/types.ts (1)

• GistSimple (44-62)

github/loaders/listOrgRepos.ts (1)

github/utils/types.ts (1)

• Repository (22-33)

github/loaders/listRepoIssues.ts (1)

github/utils/types.ts (1)

• GithubIssueClean (74-86)

🔇 Additional comments (19)

github/loaders/listOrgOutsideCollaborators.ts (1)

24-25: LGTM! Consistent with PR-wide pattern.

The implementation correctly wraps the response in { data }, aligning with MCP protocol requirements and maintaining consistency across all updated loaders.

github/loaders/listRepoWorkflowRuns.ts (1)

34-35: LGTM! Consistent implementation.

The data wrapping pattern is correctly applied, matching the structure used across all other loaders in this PR.

github/loaders/listTeamMembers.ts (1)

26-27: LGTM! Properly implements the data wrapper pattern.

github/loaders/searchIssuesAndPRs.ts (1)

28-29: LGTM! Consistent with other loaders.

github/loaders/listRepoWorkflows.ts (1)

27-28: LGTM! Correctly applies the data wrapper.

github/loaders/listOrgTeams.ts (1)

24-25: LGTM! Final loader correctly updated.

All 8 loaders now consistently return { data } wrapped responses, successfully addressing the MCP protocol requirement.

github/loaders/listRepoBranches.ts (1)

26-27: Verify impact on external consumers or establish that this is a new API not yet in use.

The breaking change is confirmed by git history (return await response.json() → return { data }), but no downstream consumers were found within this repository. Since the loader is invoked through the framework's dynamic invocation pattern (ctx.invoke), static detection of all call sites is not possible.

If this API is exposed externally or used by other projects, ensure those consumers have been updated to handle the wrapped return structure. If this is newly added or internal-only, document the expected return format for future consumers.

github/loaders/listPublicGists.ts (1)

17-22: LGTM! Good type safety with explicit return type.

The explicit return type Promise<{ data: GistSimple[] }> provides clear type safety for consumers. The implementation correctly wraps the response.

github/loaders/listAuthenticatedUserRepos.ts (1)

19-24: LGTM! Type safety maintained with explicit return type.

The implementation correctly wraps the repository array in a { data } object with proper type annotation.

github/loaders/listRepoTeams.ts (1)

26-27: LGTM! Consistent with PR-wide pattern.

The response wrapping is correctly implemented.

github/loaders/getRepoTrafficPopularReferrers.ts (1)

20-21: LGTM! Correctly wraps traffic data.

The implementation follows the consistent pattern across all loaders.

github/loaders/getRepoTrafficPopularPaths.ts (1)

20-21: LGTM! Consistent implementation.

The response wrapping correctly follows the PR pattern.

github/loaders/getRepoStatsCommitActivity.ts (1)

20-24: LGTM! Correctly preserves 202 status handling.

The implementation properly maintains the dual return type: { status: 202 } when stats aren't ready, and { data } for successful responses. This ensures consistency while preserving the existing behavior for the 202 edge case.

github/loaders/listWorkflowRunJobs.ts (1)

29-30: LGTM! Consistent with PR-wide pattern.

The implementation correctly wraps workflow run jobs data in a { data } object.

github/loaders/listRepoCommits.ts (1)

30-31: Verify PR scope: github loaders not currently consumed anywhere

Cannot locate any consumers of the github loaders being modified in this PR. No direct imports, no manifest files, and no mod.ts entry point for the github integration were found despite comprehensive search. Either this PR is adding new loaders before integration setup, or consumers exist outside this repository. Manual verification needed to confirm whether the stated concern about breaking changes across 21+ loaders actually applies.

github/loaders/listOrgRepos.ts (1)

27-32: LGTM! Return shape correctly updated for MCP protocol compliance.

The loader now wraps the repository array in a data property as required. The explicit return type annotation Promise<{ data: Repository[] }> provides clear type safety for consumers.

Note: This is a breaking change—consumers must now access repositories via result.data instead of using the result directly.

github/loaders/listRepoIssues.ts (3)

45-45: LGTM! Return type correctly reflects both success and error shapes.

The updated return type Promise<{ data: GithubIssueClean[] } | { error: true; message: string }> accurately describes the loader's behavior, allowing consumers to discriminate between successful results (with data) and error responses (with error and message).

---

90-90: LGTM! Single issue path correctly wraps result in data property.

The single issue retrieval path now returns { data: mapIssues([issue]) }, consistent with the new return shape.

---

110-110: LGTM! Multi-issue path correctly wraps result in data property.

The multi-issue retrieval path now returns { data: mapped }, maintaining consistency with the updated return shape while preserving all error handling logic.