77 lines
5.8 KiB
JSON
77 lines
5.8 KiB
JSON
[
|
|
{
|
|
"level": "critical",
|
|
"role": "Maya",
|
|
"problem": "Action 的核心邏輯 cleanupReleases 與 cleanupOrphanTags 被直接呼叫，但缺少針對清理流程的整合測試或端對端測試，僅有單元測試無法保證整個「清理 -> 再清理 tag」的完整路徑是否會因環境設定或 API 回應產生非預期的行為。",
|
|
"suggestion": "建議補上一個整合測試 (app/test/integration.test.js)，模擬完整的 API 回應序列（如：先列出舊版本 -> 刪除舊版本 -> 重新列出 release -> 列出 tag -> 刪除孤立 tag），驗證所有 API 呼叫順序與參數皆符合預期。",
|
|
"location": "app/index.js:21",
|
|
"is_new": false
|
|
},
|
|
{
|
|
"level": "critical",
|
|
"role": "Mage",
|
|
"location": "app/config.js:33",
|
|
"problem": "在 loadConfig 函式中，對 GITEA_SERVER_URL 的 replace(//+$/, '') 操作假設了輸入一定是 string。雖然隨後有 requireValue 和 requireUrl 的驗證，但如果 env.GITEA_SERVER_URL 是非字串（例如數字、陣列、物件），這裡的 replace 可能會拋出 TypeError。",
|
|
"suggestion": "應在 replace 之前確保其型別為 string，或使用 optional chaining 以及更嚴格的類型防護。例如: `typeof rawServerUrl === 'string' ? rawServerUrl.replace(//+$/, '') : rawServerUrl` 已經做了檢查，但後續的 `requireValue` 檢查順序應確保傳入的是處理後的字串。",
|
|
"is_new": true
|
|
},
|
|
{
|
|
"level": "critical",
|
|
"role": "Maya",
|
|
"location": "app/config.js:63",
|
|
"problem": "在 `loadConfig` 中，`serverUrl`、`repository`、`token` 以及 `keepCount` 雖有呼叫驗證函式，但這些驗證函式（如 `requireValue`、`requireInteger`）在失敗時會直接拋出錯誤，且沒有相對應的單元測試去驗證這些設定錯誤的情境，尤其是當環境變數輸入惡意或無效字串時的系統行為。",
|
|
"suggestion": "補上針對 `config.js` 的完整錯誤處理測試，特別是模擬 `process.env` 各項缺失或異常時，確認是否確實會拋出預期的 Error，並確保清理流程在設定錯誤時能安全停止。",
|
|
"is_new": true
|
|
},
|
|
{
|
|
"level": "critical",
|
|
"role": "Maya",
|
|
"location": "app/releases.js:45",
|
|
"problem": "在 `cleanupReleases` 函數中，儘管對 `id` 進行了 `isEmptyOrNull` 檢查，但對於 `releases` 陣列中可能存在的 `null`、`undefined` 或非預期結構的 `release` 物件，測試覆蓋僅止於 `id` 為空的情況，缺少對 `release` 本身結構異常的測試案例。",
|
|
"suggestion": "增加 `cleanupReleases` 的測試案例，模擬傳入包含異常結構（例如缺少 `tag_name` 或其他必要欄位）的 `release` 物件，確保在處理過程中不會拋出未捕捉的異常。",
|
|
"is_new": true
|
|
},
|
|
{
|
|
"level": "critical",
|
|
"role": "Maya",
|
|
"location": "app/tags.js:56",
|
|
"problem": "在 `cleanupOrphanTags` 中，雖有 `categorizeTags` 的邏輯測試，但對於 `cleanupOrphanTags` 本身與 `GiteaClient` 的整合互動，例如在 API 回傳異常 tag 列表時的處理，缺乏失敗路徑（如 API 請求失敗、JSON 解析失敗）的測試。",
|
|
"suggestion": "補上 `cleanupOrphanTags` 的整合測試，模擬 `client.fetchAllPages` 拋出例外的情境，確認清理流程是否會優雅地處理或拋出預期的錯誤。",
|
|
"is_new": true
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Mage",
|
|
"location": "app/releases.js:38",
|
|
"problem": "清理流程對網路請求依賴強,若 API 呼叫失敗,整個 main 流程中斷,無法確保後續清理的一致性與部分成功重試。",
|
|
"suggestion": "引入更細緻的錯誤處理(如錯誤閾值機制)或部分清理成功後的重試策略。",
|
|
"status": "deferred",
|
|
"defer_reason": "錯誤處理/重試策略的設計取捨。目前單筆刪除失敗會記錄並繼續、讀取失敗則中止屬合理保守行為;是否引入閾值/重試保留待人工評估。",
|
|
"is_new": false
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Maya",
|
|
"location": "app/releases.js:46",
|
|
"problem": "cleanupReleases 中若 fetchAllPages 拋錯,cleanupOrphanTags 不會執行;缺乏部分失敗後的清理與回報機制。且當 fetchAllPages 成功取得列表後，若後續刪除操作發生異常（例如網路中斷、API 回應逾時），會拋出錯誤並導致整個 cleanupReleases 流程終止，無法保證「已讀取到的所有舊 release」都被嘗試清理。",
|
|
"suggestion": "考慮在 cleanupReleases 加入 try/catch，並將逐筆刪除的迴圈包覆在 try-catch 中，即使單步驟或單筆刪除失敗，也應記錄錯誤後繼續嘗試執行後續步驟或刪除下一筆，僅該步驟失敗時記錄並仍嘗試 cleanupOrphanTags，或明確標示部分清理狀態。"
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Mage",
|
|
"location": "app/tags.js:46",
|
|
"problem": "cleanupOrphanTags 分兩次 API 呼叫取得 releases 與 tags,兩次之間若 Gitea 狀態變更,categorizeTags 可能基於不一致狀態而誤刪。",
|
|
"suggestion": "考量原子性需求,或至少在日誌標示兩次取得資料的時間間距以利除錯。",
|
|
"status": "deferred",
|
|
"defer_reason": "Gitea API 無交易機制;現行已在 cleanupOrphanTags 開頭重新抓取最新 release 作為主要緩解,殘餘競態窗極小且屬排程任務可接受範圍。是否再加每筆刪除前複查屬一致性/成本取捨,保留待人工評估。",
|
|
"is_new": false
|
|
},
|
|
{
|
|
"level": "warning",
|
|
"role": "Maya",
|
|
"location": "app/gitea-client.js:115",
|
|
"problem": "deleteResource 僅回傳狀態碼，對於 401/403/404 等錯誤未做區分處理，呼叫方策略較鬆散，且對於非 204 的處理顯得較為鬆散。",
|
|
"suggestion": "在 deleteResource 內針對常見錯誤碼拋出更有意義的例外，讓呼叫方可採取跳過/重試/中止等對應策略。"
|
|
}
|
|
]
|