[Bug]: 输入文件报错时，原始文件数据被写入 chat_run_events.payload_json，导致数据库暴涨

[qingchunnh]

Affected area

Backend / API

Version or commit

9646a8e

Environment

OS: MacOS
Browser: Chrome
Deployment: Docker
PostgreSQL: 18.4
Redis: 8.8.1

Reproduction steps

今天备份数据库时候发现的，好像是我朋友上传了大文件，然后报错了导致的。
就查了下数据库没有看源代码而且下方部分使用AI辅助不保证正确🥲

Expected behavior

用户上传的文件内容不应该写入 chat_run_events 表的 payload_json 字段，仅保存文件引用应该可以吧。（好像只有这种报错条件下会？）
正常的情况下，文件大小没有超过上限也没有模型报错的情况下，发送给模型进行对话，日志好像保存的就是文件引用。

能否添加个功能，可以在前端单独选择想删除的日志进行删除，我想单独把这几个日志删掉，进数据库里删有些麻烦。

Actual behavior

2026-07-29 09:05–09:14（UTC+8），单个用户（user_id=3）在对话 431/432 中触发了 7 次失败的运行。
每次失败运行写入 2 行（trace_block + trace_event）、每行携带相同的约 35MB 文件原始数据于 payload_json 中，共 14 行、约 350MB，全程仅 9 分钟。

进一步排查发现，不仅文件超过大小上限（35MB > 后台上限 20MB）会触发此行为，即使文件大小正常，只要过程中模型调用等环节报错，文件原始数据同样会被完整写入 payload_json。

具体表现：

• public.chat_run_events 表达到 540MB，但仅有 7,431 行
  （平均每行约 72KB，最大单行 36MB）。
• 整个数据库从约 80MB 增长到 400+MB，
  膨胀部分几乎全部来自这张表。
• input_json / output_json 字段均为空（1 字节），
  所有内容都写进了 payload_json。
• 正常时段平均每行仅 1-8KB，说明文本消息和成功运行的文件存储均正常，
  任何报错路径都可能产生数 MB 至数十 MB 的异常行。

Logs, screenshots, or request samples

-- 1. 表大小排名：chat_run_events 占整个数据库的绝大部分
   表名                     | 总大小   | 有效行数
--------------------------+---------+---------
 public.chat_run_events   | 540 MB  |   7431
 public.chat_messages     | 6000 kB |   2527

-- 2. 按小时统计写入：只有出错的那一小时异常
         小时                | 写入行数 | 平均行字节数
----------------------------+---------+-------------
 2026-07-28 21:00:00+08     |    108  |        2993
 2026-07-29 09:00:00+08     |     14  |    26191231   <-- 平均每行约26MB
 2026-07-29 10:00:00+08     |     24  |        8496

-- 3. 异常行明细（全部 status=error，同一用户，两个对话）
   id   | created_at              | event_scope | run_id               | payload大小
-------+-------------------------+-------------+----------------------+-----------
 365071 | 2026-07-29 09:07:52+08 | trace_block | run_b0606598...cfc1  | 35 MB
 365072 | 2026-07-29 09:07:54+08 | trace_event | run_b0606598...cfc1  | 35 MB
 365073 | 2026-07-29 09:09:08+08 | trace_block | run_ec35fe18...a8f   | 35 MB
 365074 | 2026-07-29 09:09:09+08 | trace_event | run_ec35fe18...a8f   | 35 MB
 ...（共 14 行 = 7 次运行 × 2 种 scope，时间范围 09:05–09:14 UTC+8）

Configuration and deployment context

No response

Pre-submit checklist

• I searched existing issues and pull requests.
• I removed secrets, tokens, credentials, and personal data from this report.
• This is not a security vulnerability report.

[qingchunnh]

后台设置的单个文件大小上限是20MB，我没测试过上传更大的文件会不会有相关提示😶

[qingchunnh]

错误提示据我朋友所说，上传的文件是图片，好像有错误显示，显示的是20480，我觉得应该改为MB单位显示吧，应该有不少人不知道这是字节数

[qingchunnh]

刚刚发现文件就算没有超过大小上限的报错也会把文件数据写入日志

[qingchunnh]

这是我朋友上传了一张几MB大小图片报错时候（模型不支持图片输入）的部分日志，图片的base64数据完整的写到日志里了，35MB的那个日志内容太长而且加载也会卡很久，所以使用了这个来提供参考

"upstream_debug": {
    "request": {
      "method": "POST",
      "path": "/v1/chat/completions",
      "body": "{\"messages\":[{\"content\":[{\"text\":\"用户输入内容\",\"type\":\"text\"},{\"image_url\":{\"url\":\"data:image/webp;base64,图片base64数据\"},\"type\":\"image_url\"}],\"role\":\"user\"}],\"model\":\"deepseek-v4-pro\",\"reasoning_effort\":\"xhigh\",\"stream\":true,\"stream_options\":{\"include_usage\":true}}"
    },

[chenyme]

收到！我来仔细排查一下～