124 lines
8.3 KiB
JSON
124 lines
8.3 KiB
JSON
[
|
||
{
|
||
"addedAt": "2026/07/20 13:53:11",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 205,
|
||
"endLine": 215,
|
||
"problem": "建立 issue 與寫入暫存留言不是可重入操作。最小重現：`createIssue` 成功後，第一則 `createCommentOnIssue` 因暫時性 500 或網路中斷而失敗；主流程退出，但已建立的 issue 不會被記錄或回貼 PR。workflow 重跑時 `issue` 又從 null 開始，因此會再建立一個內容相同的 issue，留下孤兒與重複追蹤項目。後續嚴重問題留言或 PR 回貼失敗也有相同結果。",
|
||
"reason": "Paladin：可排除（重複）。與 F004 指涉同一段 issue 建立及暫存留言沖刷流程，也描述相同的中途失敗後重跑會建立重複 issue 問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:03:30",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 205,
|
||
"endLine": 218,
|
||
"problem": "`ensureIssueCreated` 把「建立 issue」與「逐筆沖刷暫存留言」綁成一個不可恢復的流程。若 issue 已成功建立，但其中一則留言失敗，主流程會中止；下次重跑又會建立另一張 issue，留下重複且內容不完整的追蹤單。半年後維護者也很難從現有狀態判斷應重試留言、沿用既有 issue，還是重新建立。",
|
||
"reason": "Paladin：可排除（命中已知排除事項）。其指涉的正是 issue 建立成功、留言沖刷失敗後重跑會產生重複追蹤單的同一問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 179,
|
||
"endLine": 234,
|
||
"problem": "`main()` 新增了留言路由、issue 狀態、緩衝佇列、issue 建立與緩衝留言沖刷等職責，後續流程又多次以 `ctx.createIssue` 分支決定發布方式。這使主流程同時負責審查編排與發布狀態機；六個月後若再增加發布管道或重試策略，模式判斷會繼續散落，難以獨立測試各種狀態轉換。",
|
||
"reason": "Paladin：可排除（重複）。與 F006 指涉同一段 main() 內的留言路由、issue 狀態及緩衝佇列職責，亦提出相同的發布器抽離方向。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 213,
|
||
"endLine": 233,
|
||
"problem": "`ensureIssueCreated` 在建立 issue 後逐則寫入 `issueBuffer`，但整段沒有可恢復或冪等機制。若寫到一半 API 失敗，主流程會中止；重新執行時無法辨識已建立但內容不完整的 issue，因而可能再建立一張重複 issue。這類部分完成狀態日後會很難人工清理與追查。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且與歷史 finding 重複）。其描述的 issue 建立後沖刷留言失敗、重跑產生重複 issue，正是既有排除事項與歷史 finding 已記錄的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Leo",
|
||
"severity": "建議",
|
||
"file": "src/lib/gitea.js",
|
||
"startLine": 171,
|
||
"endLine": 194,
|
||
"problem": "新增並匯出的 `addLabelsToIssue` 沒有被本次流程使用，註解也明確表示主流程已不再需要它。保留這個預想中的通用 API 會擴大公開介面與測試範圍；未來 Gitea API 行為改變時，維護者仍得判斷這個無使用者的函式是否需要同步修改。",
|
||
"reason": "Paladin：可排除（重複）。與 F007 指涉相同的未使用 addLabelsToIssue 函式及匯出，問題與移除建議均相同。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Mage",
|
||
"severity": "嚴重",
|
||
"file": "src/index.js",
|
||
"startLine": 331,
|
||
"endLine": 331,
|
||
"problem": "建問題模式在此直接建立新的追蹤 issue，卻沒有任何可重入或去重機制。最小重現：issue 建立成功後，寫入 `issueBuffer`、發布 finding、回貼 PR 連結或最後 push 任一步驟失敗，整個 Action 會以失敗結束；重新執行同一個 commit 時仍會再次呼叫 `ensureIssueCreated`，因此產生內容相同的重複 issue。失敗若持續發生，每次重跑都會再新增一筆。",
|
||
"reason": "Paladin：可排除（命中已知排除事項且與 F009、歷史 finding 重複）。同樣是建立 issue 後任一步驟失敗，重跑無法沿用既有 issue 而重複建立的問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 190,
|
||
"endLine": 238,
|
||
"problem": "新增的一般模式／建問題模式留言分流與 `issueBuffer` 清空流程，這次 diff 沒有對應測試。尚未驗證 issue 建立前留言只暫存、建立後依序送出、建立後的新留言直接送往 issue，以及任一 API 寫入失敗時的行為；這是本次建問題模式的核心路徑，沒有測試即無法確認留言不會遺失、重複或誤發到 PR。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已明確涵蓋建問題模式核心流程、暫存留言依序送出、發布分流及外部 API 狀態切換缺乏測試。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 312,
|
||
"endLine": 389,
|
||
"problem": "建問題模式新增了「無 finding 靜默通過」「有 finding 才建 issue」「標籤失敗降級」「嚴重／其他問題分流」「PR 回貼連結」「相依 API 失敗不阻斷」等多個分支，但本次 diff 沒有測試驗證這些結果。尤其 `kept`、`severe`、`others` 的空集合組合與 API 失敗路徑未經試煉，重構後很容易出現 `issue` 為 null 卻被取用、建立空 issue，或意外在 PR 留言。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已列出有問題才建立 issue、無問題靜默通過、嚴重與非嚴重問題分流、標籤失敗及 PR 回貼等相同未測試分支。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/gitrepo.js",
|
||
"startLine": 103,
|
||
"endLine": 157,
|
||
"problem": "`resolveMergeBase` 新增多階段 fetch／重試狀態機，卻沒有新增測試驗證策略順序與停止條件。未驗證非 shallow、`--unshallow` 成功、各 fetch 失敗、補抓後仍無共同祖先等邊界，可能讓正常 checkout 多做 fetch，或在仍可恢復時提早拋錯。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已針對 resolveMergeBase 的多階段 fetch、淺層與非淺層分支、降級及最終失敗路徑缺少測試提出相同問題。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Maya",
|
||
"severity": "警告",
|
||
"file": "src/lib/review.js",
|
||
"startLine": 16,
|
||
"endLine": 77,
|
||
"problem": "新增的失敗診斷與機密遮罩會處理 CI 日誌中的敏感輸出，但本次 diff 沒有測試其邊界與失敗情境。未驗證 debug 預設關閉、大小寫／空白解析、控制字元單行化、各 token 格式遮罩、500 字截斷，以及 `error`／`stderr`／`output` 缺漏時仍能穩定回傳摘要。",
|
||
"reason": "Paladin：可排除（與歷史 finding 重複）。歷史 finding 已指出 agent 失敗診斷的退出狀態、空輸出、單行化與截斷等邊界缺少測試；本條只是進一步枚舉相同測試缺口。"
|
||
},
|
||
{
|
||
"addedAt": "2026/07/20 15:26:21",
|
||
"prNumber": 6,
|
||
"reviewer": "Rogue",
|
||
"severity": "警告",
|
||
"file": "src/index.js",
|
||
"startLine": 226,
|
||
"endLine": 228,
|
||
"problem": "`issueBuffer` 內每則留言以 `await` 串行送出，建立 issue 的等待時間會線性累加為約 `留言數 × API RTT`；若每次往返 200～500 ms，6 則留言便額外卡住約 1.2～3 秒。",
|
||
"reason": "Paladin：可排除（誤判）。此處逐筆 await 用來維持暫存留言的 FIFO 發布順序；留言數量有限，所述短暫延遲不足以證明缺陷，而改成並行反而可能破壞順序並增加 API 限流風險。"
|
||
}
|
||
]
|