请求记录显示异常：所有字段为空且状态卡在请求中，最终导致进程崩溃重启

[s6yoho]

环境

• 版本: v0.6.1
• 部署方式: Docker

问题描述

Dashboard 日志页面中，请求记录持续显示异常状态：

• Tokens: -
• 缓存: -
• 成本: $0.000000
• 性能: -
• 状态: 一直显示 请求中

所有字段均为空/默认值，但实际上消息是正常处理并返回的（客户端可以正常收到响应）。

这种异常记录会持续累积，最终导致进程崩溃并自动重启。

复现情况

• 同一个 Session ID 下的多个请求均出现此问题
• 不同 Session ID 也会出现（如 2b806e73-... 和 63a33c46-...）
• 使用模型: claude-opus-4-6

异常记录示例

时间	Session ID	计费模型	Tokens	缓存	成本	状态
25秒前	2b806e73-...	claude-opus-4-6	-	-	$0.000000	请求中
1分前	2b806e73-...	claude-opus-4-6	-	-	$0.000000	请求中
7分前	63a33c46-...	claude-opus-4-6	-	-	$0.000000	请求中

同一个 Session 短时间内产生大量状态为"请求中"的记录，且永远不会更新为完成状态。

预期行为

• 请求完成后，状态应更新为"完成"，并正确显示 Tokens、成本等计费信息
• 不应因日志记录异常导致进程崩溃

实际行为

1. 请求记录的状态永远卡在"请求中"
2. 所有计费字段显示为空或 $0.000000
3. 异常记录持续累积
4. 最终进程崩溃重启
5. 但客户端消息实际上是正常处理和返回的

[github-actions]

Thank you for reporting this issue.

Analysis

Based on my investigation of the codebase, this appears to be a request status tracking issue where the statusCode field in the message_request table is not being properly updated when responses complete.

Key Findings

1. Status Display Logic

The UI displays "请求中" (in progress) when statusCode is null:

• src/app/[locale]/dashboard/logs/_components/error-details-dialog/index.tsx (line 111):

  const isInProgress = statusCode === null;

2. Status Update Paths

The statusCode should be updated via updateMessageRequestDetails() in multiple locations:

• src/app/v1/_lib/proxy/response-handler.ts - Handles successful/failed response completion
• src/app/v1/_lib/proxy/error-handler.ts - Handles error cases

3. Potential Root Causes

Based on your symptoms (requests showing as "in progress" but clients receiving responses, followed by process crash), the most likely causes are:

1. Async Write Buffer Issue: If MESSAGE_REQUEST_WRITE_MODE=async is configured, status updates are buffered and written in batches. If the process crashes before the buffer flushes, updates are lost.

   • Relevant code: src/repository/message-write-buffer.ts
   • Buffer settings: MESSAGE_REQUEST_ASYNC_FLUSH_INTERVAL_MS (default 250ms), MESSAGE_REQUEST_ASYNC_MAX_PENDING (default 5000)

2. Streaming Response Crash: If the process crashes during streaming response handling, the final status update may never execute.

3. Database Connection Issues: If DB writes fail during updateMessageRequestDetails(), the status remains null.

Potentially Affected Code

• src/repository/message.ts:121-209 - updateMessageRequestDetails() function
• src/repository/message-write-buffer.ts:153-308 - Async write buffer implementation
• src/app/v1/_lib/proxy/response-handler.ts:1825-1840 - Streaming response finalization

Diagnostic Information Needed

To help diagnose this issue, please provide:

1. Environment configuration:

   • Value of MESSAGE_REQUEST_WRITE_MODE (is it set to async?)
   • Any related MESSAGE_REQUEST_ASYNC_* settings

2. Server logs:

   • Any error messages or stack traces before the process crash
   • Look for [MessageRequestWriteBuffer] related log entries

3. Database state:

   • For a stuck request (showing "请求中"), what are the values of status_code, duration_ms, error_message, and provider_chain in the message_request table?

4. Reproduction details:

   • Does this happen for all requests or only certain models/providers?
   • Are the affected requests using streaming (stream: true) or non-streaming mode?

Potential Workaround

If MESSAGE_REQUEST_WRITE_MODE=async is set, try changing it to sync (or removing it to use the default synchronous mode). This will ensure status updates are written immediately, though it may slightly increase response latency.

---

Automated response from Claude AI

[s6yoho]

又出现了 @ding113

麻烦大佬有空修复下这个问题..
出现这种情况.消息虽然能正常处理,但是内存疯涨.时间长就崩掉了

[miraserver]

这种情况是在什么条件下产生的？是因为某些逆向通道（Reverse channels）或者非标准供应商吗？是在所有供应商那里都会出现这种情况，还是只针对特定的几个？我经常配合纯净通道使用 cch，并且会一直盯着日志看，但我从来没遇到过这个问题

[s6yoho]

我也不清楚是什么条件.就是突然出现的. 今天观察一天中午出现了一次,但是下午到现在又没出现了(可能跟我关了cpa供应商有关系).

只要出现了 后面不管什么供应商,都是显示请求中.

我刚刚查了一下日志. 第一次出现这种 "请求中" 供应商好像都是我自建的 cliproxyapi 供应商.
然后类型都是claude类型. claude-sonnet-4-6 claude-opus-4-6
感觉供应商没有什么特别的,就是挪了两个到 cpa里用了

反正我 没搞明白. 明天我再把cpa接进来观察看看