Security alert list tools return inconsistent JSON response shapes
維護者通常 4 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
從 pkg/github/dependabot.go 開始，查看它所建構的物件形狀（Alerts 加 PageInfo），然後與 pkg/github/code_scanning.go 及 pkg/github/secret_scanning.go 中的 marshalling 進行比較，後者輸出的是裸陣列。更新這兩個清單工具，使其回傳相同的 {alerts, pageInfo} 契約，並調整既有的分頁中繼資料。當 pkg/github/ 中針對這三個清單工具的既有測試在新形狀下全部通過，並在不存在時補上一個斷言頂層 alerts 屬性的測試案例時，即為完成。
由索引模型根據 Issue 內容生成。
描述
Describe the bug
The security alert list tools expose inconsistent JSON response shapes.
list_code_scanning_alerts and list_secret_scanning_alerts return their text payload as a bare JSON array:
[{"number":274,"rule":{"id":"py/unused-import"}}]
while list_dependabot_alerts returns an object:
{"alerts":[{"number":16}],"pageInfo":{"hasNextPage":false,"hasPreviousPage":false}}
This makes closely related security-list tools difficult to consume uniformly and can cause a client to interpret real findings as an empty result when it expects the Dependabot-style alerts property.
The implementation difference appears to be:
pkg/github/code_scanning.gomarshalsalertsdirectlypkg/github/secret_scanning.gomarshalsalertsdirectlypkg/github/dependabot.gobuilds an object containingAlertsandPageInfo
Affected version
v1.14.0
Steps to reproduce the behavior
- Call
list_code_scanning_alertsfor a repository with an open finding. - Observe that the text payload is a bare JSON array.
- Call
list_secret_scanning_alertsand observe the same shape. - Call
list_dependabot_alertsand observe{ "alerts": [...], "pageInfo": {...} }instead.
We reproduced this during a repository-wide Security & Quality audit. A real open CodeQL finding was present in the returned array but was initially missed by a consumer expecting the Dependabot response shape.
Expected vs actual behavior
Expected: the related security alert list tools expose a consistent top-level contract, preferably { "alerts": [...], "pageInfo": {...} } where pagination metadata applies.
Actual: Code Scanning and Secret Scanning return bare arrays, while Dependabot returns an object.
If the difference is intentional, documenting it explicitly would also help clients avoid incorrect assumptions.
Logs
No server error is produced; this is a response-shape inconsistency.
We currently normalize the two bare-array responses in a local compatibility gateway, but an upstream-consistent contract would remove the need for that workaround.
- 主要語言
- Go
- 星號
- 33.4k
- 分支
- 5.1k
- 平均合併
- 3 天 1 小時
- 30 天內合併 PR
- 35
環境準備
- 提供 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
github/github-mcp-server 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 76/100
github/github-mcp-server#3450 ·
維護者通常 4 天內回覆
-
get_job_logs with failed_only misses failed jobs after the first 30 jobs of a run可能已有人在做 @jayhemnani9910 於 3 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 74/100
github/github-mcp-server#3428 ·
維護者通常 4 天內回覆
-
create_or_update_file writes to the wrong file when the path contains # or ?可能已有人在做 @jayhemnani9910 於 3 天前認領。 未關閉
難度 2/5 1-3 小時 新手友好度 84/100
github/github-mcp-server#3427 ·
維護者通常 4 天內回覆
-
pull_request_read drops merge_commit_sha可能已有人在做 @thejdubb02 於 31 天前認領。 未關閉bug
難度 2/5 1-3 小時 新手友好度 84/100
github/github-mcp-server#3235 · 1 則留言 ·
維護者通常 4 天內回覆
-
Add guidance on GitHub autolinked reference formatting for AI agents可能重新可做 關聯的 PR 已關閉且未合併。 未關閉enhancement
難度 1/5 1 小時以內 新手友好度 88/100
github/github-mcp-server#3042 · 2 則留言 ·
維護者通常 4 天內回覆
查看 github/github-mcp-server 的全部 Issue
相似的 Issue
-
難度 1/5 1 小時以內 新手友好度 88/100
維護者通常 1 天內回覆
-
agent-research agent-review-finding chore
難度 2/5 1-3 小時 新手友好度 66/100
jordansmall/spindrift#4922 ·
維護者通常 1 天內回覆
-
gcsartifact: deleting a missing version returns an error可能已有人在做 @ktsoator 今天認領。 未關閉bug
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 2 天內回覆
-
govulncheck
難度 2/5 1-3 小時 新手友好度 62/100
維護者通常 1 天內回覆
-
Change wording for init command success message可能已有人在做 關聯的 PR 仍在進行中或已合併。 未關閉
難度 1/5 1 小時以內 新手友好度 82/100
維護者通常 1 天內回覆