81 lines
4.2 KiB
JSON
81 lines
4.2 KiB
JSON
[
|
||
{
|
||
"level": "critical",
|
||
"role": "Maya",
|
||
"location": "app/releases.js:46",
|
||
"problem": "清理舊版本成品時，若刪除過程拋出例外或 API 回傳異常(除 204 外)，未作完善處理，導致無法保證一致性且未針對「部分失敗」設計重試或完整性檢查機制。",
|
||
"suggestion": "將逐筆刪除包在 try/catch，加入錯誤計數；若失敗率過高或發生特定非預期錯誤(如 403)，應明確拋出例外讓流程終止。"
|
||
},
|
||
{
|
||
"level": "critical",
|
||
"role": "Assassin",
|
||
"location": "app/releases.js:77",
|
||
"problem": "儘管使用了 encodeURIComponent(id)，若後續處理中 id 被錯誤地解碼或拼接，仍存在目錄穿越風險（API 路徑穿越）。",
|
||
"suggestion": "除了 encodeURIComponent，需確保 cleanupReleases 迴圈中對 id 為正整數的驗證邏輯不能被繞過，且移除 id 上的任何類型轉換風險。"
|
||
},
|
||
{
|
||
"level": "warning",
|
||
"role": "Mage",
|
||
"location": "app/tags.js:52",
|
||
"problem": "cleanupOrphanTags 分兩次 API 呼叫取得 releases 與 tags，過濾過程未保證原子性，期間 Gitea 狀態變更可能誤刪非孤立 tag。",
|
||
"suggestion": "考量原子性需求，或在刪除前增加確認機制，並明確文件化此風險。"
|
||
},
|
||
{
|
||
"level": "warning",
|
||
"role": "Mage",
|
||
"location": "app/releases.js:38",
|
||
"problem": "清理流程對網路請求依賴強，若 API 呼叫失敗，整個 main 流程中斷，無法確保後續清理的一致性與部分成功重試。",
|
||
"suggestion": "引入更細緻的錯誤處理（如錯誤閾值機制）或部分清理成功後的重試策略。"
|
||
},
|
||
{
|
||
"level": "warning",
|
||
"role": "Maya",
|
||
"location": "app/releases.js:47",
|
||
"problem": "cleanupReleases 迴圈逐筆 await deleteResource，release 眾多時依序刪除耗時，且 API 負載高時易逾時。",
|
||
"suggestion": "若 API 允許，採有上限的併發刪除（如限流 Promise.all），或增加進度日誌與重試。"
|
||
},
|
||
{
|
||
"level": "warning",
|
||
"role": "Maya",
|
||
"location": "app/tags.js:54",
|
||
"problem": "刪除 tag 的迴圈缺少對 deleteResource 拋例外的防禦，網路錯誤會中止後續 tag 清理。",
|
||
"suggestion": "在 for 迴圈內加 try/catch，記錄錯誤並 continue；比照 releases 補測試。"
|
||
},
|
||
{
|
||
"level": "warning",
|
||
"role": "Maya",
|
||
"location": "app/gitea-client.js:115",
|
||
"problem": "deleteResource 僅回傳狀態碼，對 401/403/404 等錯誤未做區分處理。",
|
||
"suggestion": "在 deleteResource 內針對常見錯誤碼拋出更有意義的例外，讓呼叫方採取跳過/重試/中止策略。"
|
||
},
|
||
{
|
||
"level": "warning",
|
||
"role": "Mage",
|
||
"location": "app/releases.js:21",
|
||
"problem": "在 selectReleasesToDelete 函式中，若 releases 陣列為空，雖不拋錯但邏輯上應考慮空值邊界。且雖然處理了 Date.parse 的 NaN，但對空物件或缺失 created_at 屬性的項目的處理依賴屬性存取鏈，可能在特定結構下產生非預期行為。",
|
||
"suggestion": "建議增加對釋出項目結構的預防性檢查，確保 created_at 存在且有效。",
|
||
"is_new": true
|
||
},
|
||
{
|
||
"level": "warning",
|
||
"role": "Maya",
|
||
"location": "app/test/gitea-client.test.js:150",
|
||
"problem": "fetchAllPages 目前缺乏測試當 fetch 自身發生網路錯誤時的情境。",
|
||
"suggestion": "補上一個測試案例，模擬 fetch 拋出非 AbortError 的一般網路錯誤，以驗證客戶端能妥善捕捉並拋出具備 URL 上下文的錯誤。"
|
||
},
|
||
{
|
||
"level": "info",
|
||
"role": "Bard",
|
||
"location": "app/index.js:30",
|
||
"problem": "手動拼接 import.meta.url 字串來判斷執行入口，寫法原始且脆弱。",
|
||
"suggestion": "引用 node:url 中的 pathToFileURL，使用 import.meta.url === pathToFileURL(process.argv[1]).href 進行比較。"
|
||
},
|
||
{
|
||
"level": "info",
|
||
"role": "Maya",
|
||
"location": "app/test/releases.test.js:30",
|
||
"problem": "selectReleasesToDelete 尚未明確測試傳入空陣列 [] 時的行為。",
|
||
"suggestion": "增加測試案例：assert.deepEqual(selectReleasesToDelete([], 1), [])，驗證穩健性。"
|
||
}
|
||
]
|