Files
code-review/.gitea/ai-review/findings.json
T
AI Review Bot 0fdd6c1d0b
AI / 計算版本號 (pull_request) Successful in 2s
AI / Code Review (pull_request) Failing after 3s
chore: update ai-review findings [ai-review-bot][failure]
2026-06-23 08:45:25 +00:00

27 lines
2.0 KiB
JSON
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
[
{
"level": "critical",
"role": "Mage",
"problem": "測試情境雖處理了 NaN,但未涵蓋 `limit` 為 0 或負數等極端數值(例如除以零導致的錯誤或異常百分比計算)。若 `formatUsageStatsLine` 內部有計算 `(used / limit) * 100` 或類似邏輯,傳入 0 會產生 `Infinity`,傳入負數則會產生荒謬的邏輯結果。",
"suggestion": "建議新增對 `limit: 0` 以及負數邊界值的測試案例,確保函式對這些非預期的數值輸入同樣能輸出「無法計算」或相應的錯誤處理訊息,而非輸出 `Infinity` 或負百分比。",
"location": "app/usage.test.js:254",
"is_new": false
},
{
"level": "warning",
"role": "Bard",
"location": "app/usage.test.js:200",
"problem": "測試迴圈中的陣列 `[0, -5, Infinity, NaN, undefined]` 直接混用了不同型別與邊界值,雖然測試目的明確,但在測試碼中,將邏輯測試與邊界測試分開撰寫會更具可讀性。",
"suggestion": "建議將測試案例拆分,例如分開測試「非數字類型」、「負數」與「邊界值(Infinity/NaN)」,這樣在測試失敗時能更快速釐清是哪種輸入類型導致的問題。",
"is_new": true
},
{
"level": "warning",
"role": "Maya",
"location": "app/usage.js:216",
"problem": "新增的 `isFinitePositive` 函數雖然確保了大於 0,但當 `n` 是類似 \"100\" 的數字字串時,`Number(n)` 可以正常運作,然而如果是 `null` 或 `undefined``Number(n)` 分別會變成 `0` 和 `NaN`。雖然在目前的使用邏輯下(`limit != null`)似乎安全,但這個檢查函數本身沒有對 `null`/`undefined` 做明確的防禦性處理,容易在未來被錯誤複用。",
"suggestion": "建議在 `isFinitePositive` 內部補上對 `null` 或 `undefined` 的顯式檢查,或是增加對輸入型別的限制,確保該函數作為基礎邏輯檢查更健壯。",
"is_new": true
}
]