Repository navigation
Conversation
coerceTestUsage returned a typed nil *dto.Usage as a valid usage, so testChannel dereferenced it and the scheduled channel-test worker goroutine panicked, killing the whole process. Treat a typed nil usage like a nil usage, and recover panics per channel in runChannelTestWorkers so one bad test is counted as failed without changing the channel status. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Usage conversion and validation controller/channel-test.go, controller/channel_test_panic_test.go |
coerceTestUsage normalizes typed nil *dto.Usage values. Tests cover XAI responses without usage and pointer, value, nil, and invalid usage inputs in streaming and non-streaming cases. |
Worker panic recovery controller/channel-test.go, controller/channel_test_panic_test.go |
Workers call runChannelTestSafely. The helper recovers from panics and returns one tested, failed result. A worker test checks progress, summary counts, continued processing, and unchanged channel status. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix
Possibly related PRs
- QuantumNous/new-api#8026: Changes the estimated prompt tokens used by the streaming channel-test fallback.
Suggested reviewers: seefs001
Merge Risk: 
Minimal · up to f2f73
-
Recovered channel-test panics are reported as failed tests while other channels continue. No actionable merge-blocking risk was identified.
Pre-merge checks: 
4 · 
1
-
Failed checks: 1 warning Passed checks: 4 passed -
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
A rabbit checks the channels one by one
When usage hides, the tests still run
If panic leaps, the worker keeps its pace
A failed result takes its proper place
The stack trace leaves a trail to see
Then hops along, calm as can be
Comment @coderabbitai help to get the list of available commands.
Agent
本 PR 代码由 AI 辅助生成(提交者不是本仓库的历史核心开发者),已经人工确认方向。
Links
User request
Out of scope — refuse
Open gate — do not open unless all are satisfied
go buildor tests passed: yesKind
Issue facts
monitor_setting.auto_test_channel_enabled)后,后台检测 worker 发生 nil pointer panic,整个进程退出(Docker 退出码 2)。栈(已脱敏):new-api:3000,API 与控制台同时 502。v1.0.0-rc.47(e835b1bf),检测每 3 分钟一次,并发 10;容器累计重启 42 次,留存的 42 份 panic 都在 499 行。connect() failed (111: Connection refused);没有 OOM 记录。只关闭auto_test_channel_enabled、不重启也不改代码后,15 分钟内没有新的 panic、重启或 502。calciumion/new-api:v1.0.0-rc.47,PostgreSQL + Redis;relay / billing / frontend 不适用。Change
coerceTestUsage:adaptor 的DoResponse可能返回装在any里的(*dto.Usage)(nil),它不等于 nil 接口,会命中case *dto.Usage并被当作有效 usage 返回,随后在 499 行usage.PromptTokens处解引用。现在进入类型判断前先把它当作 nil 处理:流式请求按估算 usage 处理,非流式返回usage is nil,与原有 nil 分支一致。runChannelTestWorkers:worker goroutine 中的 panic 不会被 gin 的 recover 中间件捕获,会直接终止进程。现在每个渠道的检测都在runChannelTestSafely中 recover,记录渠道信息和栈,计为 1 次失败,不修改渠道状态,然后继续检测下一个渠道。Research
Duplicate / prior art
coerceTestUsage,channel test panic,nil pointer channel-test,testChannelForHealthCheck,自动测试 渠道 panic,auto test channel crash, PR searchchannel-test.go panicDocs and code
controller/system_task_handlers.go中,定时任务和手动“测试所有渠道”都通过runChannelTestTask→performChannelTests→runChannelTestWorkers,因此两种触发方式都会崩溃,修在 worker 层可以同时覆盖。单渠道测试接口在 gin handler 内运行,有 recover 中间件,但同样会因为 typed nil 返回 500,第一处修复也覆盖了这种情况。Alternatives considered
coerceTestUsage。能修掉这次的 panic,但以后其他 adaptor 再出类似问题,仍然会导致全站宕机。Files
controller/channel-test.gocontroller/channel_test_panic_test.goBehavior
Verification
channel-test.go后运行go test ./controller/ -run 'TestCoerceTestUsage|TestRunChannelTestWorkers' -count=1:--- FAIL: TestCoerceTestUsage,测试进程以panic: runtime error: invalid memory address or nil pointer dereference退出,与生产现象一致。ok github.com/QuantumNous/new-api/controller。go vet ./controller/:无输出。gofmt -l controller/:无输出。go test ./controller/ -count=1:ok github.com/QuantumNous/new-api/controller 35.233s。e835b1bf(rc.47),cherry-pick 本 PR 的提交(无冲突),按官方 Dockerfile 相同参数编译成镜像,然后重新开启auto_test_channel_enabled(3 分钟,并发 10,passive_recovery):go test ./controller/ -count=1:ok ... 34.947s。system_tasks.result:{"tested":14,"succeeded":7,"failed":7,"enabled":7}、{"tested":7,"succeeded":0,"failed":7}、{"tested":9,"succeeded":4,"failed":5,"enabled":4}。失败均为上游返回的 400/429。RestartCount为 0;日志中^panic与channel test panic均为 0 次。修复前,同一配置下累计重启了 42 次。TestCoerceTestUsage覆盖 nil、typed nil、指针、值、非法类型在流式和非流式下的组合;TestRunChannelTestWorkersContinuesAfterPanic验证 panic 之后继续处理后续渠道,进度、汇总结果正确,且渠道状态不变。Risks
channel test panic,需要通过日志发现这类问题。Scope check
🤖 Generated with Claude Code
Summary by CodeRabbit