JefferyandClaude Opus 4.8
1cc217f04e
CI / AI Code Review (pull_request) Failing after 50s
移除本輪已修復(Date.parse 預算、結束碼/sanitizeBody/logger 測試)的 finding; 保留 7 條設計取捨類(重試/錯誤閾值/SRP/並行化/回應大小 DoS 防護); 將 6 條不適用或誤報(Node<16、push.apply、'null' 字串、已用 Set、env 可注入、 Set 轉換)登記至 exclusions。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
66 lines
4.1 KiB
JSON
66 lines
4.1 KiB
JSON
[
|
|
{
|
|
"level": "warning",
|
|
"role": "Mage",
|
|
"location": "app/releases.js:38",
|
|
"problem": "清理流程對網路請求依賴強,若 API 呼叫失敗,整個 main 流程中斷,無法確保後續清理的一致性與部分成功重試。",
|
|
"suggestion": "引入更細緻的錯誤處理(如錯誤閾值機制)或部分清理成功後的重試策略。",
|
|
"status": "deferred",
|
|
"defer_reason": "與 app/releases.js:46 同屬錯誤處理/重試策略的設計取捨。目前單筆刪除失敗會記錄並繼續、讀取失敗則中止屬合理保守行為;是否引入閾值/重試保留待人工評估。"
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Mage",
|
|
"location": "app/releases.js:46",
|
|
"problem": "刪除邏輯未針對特定 HTTP 狀態碼(502, 503, 504)實作重試機制,且遇到失敗時未停止後續請求。",
|
|
"suggestion": "針對特定 HTTP 狀態碼實作指數退避重試並引入錯誤閾值;資料量龐大時考慮分批/串流讀取。",
|
|
"status": "deferred",
|
|
"defer_reason": "重試/退避/錯誤閾值涉及次數、間隔與冪等性等設計決策;清理 Action 以排程執行,單次失敗可於下次補刪。分頁已有 MAX_PAGES 上限,實務上 release/tag 數量有限,串流化屬最佳化取捨,保留待人工評估。"
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Leo",
|
|
"location": "app/releases.js:37",
|
|
"problem": "cleanupReleases 同時處理資料獲取、邏輯判斷與副作用執行,違反單一職責原則。",
|
|
"suggestion": "拆分邏輯與執行層,將刪除副作用抽象化為獨立函式。",
|
|
"status": "deferred",
|
|
"defer_reason": "純邏輯(selectReleasesToDelete)已抽離且函式短小、已具失敗路徑與編碼測試;進一步拆出刪除迴圈為設計偏好,效益有限,保留待人工評估。"
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Rogue",
|
|
"location": "app/releases.js:43",
|
|
"problem": "清理成品與刪除 tag 使用序列化迴圈,API 請求逐一排隊,整體執行時間拉長。",
|
|
"suggestion": "改用 Promise.all 搭配 map 將刪除請求並行化。",
|
|
"status": "deferred",
|
|
"defer_reason": "刻意保留序列化:避免對 Gitea API 造成併發壓力與觸發速率限制,並維持可預期的記錄輸出順序;無上限並行化非等價變更,保留待人工評估(可日後改為有上限並行)。"
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Assassin",
|
|
"location": "app/gitea-client.js:66",
|
|
"problem": "錯誤路徑以 res.text() 讀取整個回應主體,未限制大小,惡意伺服器可回傳極大內容導致記憶體耗盡(DoS)。",
|
|
"suggestion": "限制讀取的回應大小,例如檢查 Content-Length 或以串流方式設定讀取上限。",
|
|
"status": "deferred",
|
|
"defer_reason": "風險低:目標為已通過 URL 驗證的受信任 Gitea 實例,需伺服器被入侵或中間人攻擊才成立,且每請求已有 30 秒逾時部分約束。正確修法需以串流逐段讀取並設位元組上限(Content-Length 在 chunked 回應下不可靠),屬較大改動,保留待人工評估。"
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Assassin",
|
|
"location": "app/gitea-client.js:77",
|
|
"problem": "成功路徑以 res.json() 解析整個回應,未限制大小,惡意伺服器可回傳極大 JSON 導致記憶體耗盡(DoS)。",
|
|
"suggestion": "對 API 回應設定明確大小上限,超過時拒絕解析並拋出異常。",
|
|
"status": "deferred",
|
|
"defer_reason": "與 app/gitea-client.js:66 同類:受信任目標、已有逾時與 MAX_PAGES 約束,風險低;正確修法需串流讀取並設上限,屬較大改動,保留待人工評估。"
|
|
},
|
|
{
|
|
"level": "info",
|
|
"role": "Rogue",
|
|
"location": "app/gitea-client.js:33",
|
|
"problem": "fetchAllPages 採線性逐頁請求,資料龐大時效能不佳。",
|
|
"suggestion": "若 API 支援,先取得總頁數後並行請求。",
|
|
"status": "deferred",
|
|
"defer_reason": "Gitea 分頁未可靠提供總頁數,需解析 Link 標頭且各端點支援度不一;線性逐頁搭配逾時與 MAX_PAGES 上限已足夠穩健,並行化屬最佳化取捨,保留待人工評估。"
|
|
}
|
|
]
|