fix(consultation): count visible text only for session quota (BUG-732)
Replace append_consultation_question so the 200,000 quota sums only user-visible text, and add a 1,000,000-byte whole-JSON physical cap. Both still return session_full. Advisory lock, request_id idempotency, and the 200-message cap are unchanged.
This commit is contained in:
jesse-ux
@@ -0,0 +1,62 @@
|
||||
# PROGRESS · 对话上限一半被思考文本吃掉（2026-09-15）
|
||||
|
||||
工作树：`.worktrees/consultation-session-capacity-20260915`
|
||||
分支：`codex/consultation-session-capacity-20260915`
|
||||
任务书基线：`6b3248bf`；开工时 `origin/staging` = **`11893c7f`**。
|
||||
本机 Windows。无 Docker。
|
||||
|
||||
未改 `frontend/src/app/api/consult/route.ts`、`page.tsx`、Skill。未 bump Skill。BUG 号核对：该 SHA 最大号仍是 **BUG-720**，本单用预占 **BUG-732**，无冲突。
|
||||
|
||||
| 任务 | 状态 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| 5.1 对话额度只数 `text` | 完成（运行时 DB 为环境缺口） | 新迁移 `20260916010000_consultation_session_capacity.sql` `CREATE OR REPLACE`；`v_chars` 只 `sum(length(elem->>'text'))` |
|
||||
| 5.2 物理上限 `length(elem::text)` | 完成（同上） | 算式见下；两档都返回 `session_full` |
|
||||
| 5.3 详情接口体积 | 完成（夹具量过） | 见下表；1.41 MiB 写入 `BLOCKED.md` 观察，本单不改接口 |
|
||||
| 5.4 BUG-732 | 完成 | 关联 BUG-464；不是回归 |
|
||||
|
||||
## 实现要点
|
||||
|
||||
- 只新增一份迁移。函数签名、返回列、`error_code` 取值、advisory lock、`request_id` 幂等、200 条上限、`char_length(v_text) > 16000` 均未改。
|
||||
- 物理上限算术（迁移注释原文）：50 rounds × (~4,000 body + ~4,000 thinkingText + ~3,000 thinkingSections + ~3,000 receipts) ≈ 700,000。Headroom → 1,000,000。
|
||||
- 实测 receipt（典型三域本命：12 行技法审计 + workflow + agentExecutionReceipt）JSON **1,738 字符 / 1,950 字节**，小于任务书 3,000，**不调高** 1,000,000。
|
||||
- 实测 `thinkingSections` JSON 字符：1 域 1,246、2 域 1,968、3 域 2,702（任务书 1,521 / 2,243 / 2,977，同量级，计划文案有漂移）。
|
||||
- 未删、未截断任何已存字段。
|
||||
|
||||
## 详情 JSON 体积（5.3）
|
||||
|
||||
夹具：每轮用户提问 100 汉字 + 助手正文 4,000 汉字 + 思考 4,000 汉字 + 三域 `natalConsultationThinkingPlan` + 上面那份典型 receipt。`GET /api/sessions/[id]` 的 `{ session }`（`sessionSelect` 含 `messages`）。
|
||||
|
||||
| 口径 | 轮次 | UTF-8 字节 | MiB |
|
||||
| --- | ---: | ---: | ---: |
|
||||
| 改前（旧合并额度大约卡住的地方） | 19 | 562,240 | 0.536 |
|
||||
| 改后（任务书字符口径约 50 轮） | 50 | 1,479,034 | 1.411 |
|
||||
|
||||
50 / 19 ≈ **2.63**。1.411 MiB 在 2 vCPU 上打开长会话会偏沉，观察项进 `BLOCKED.md`；分页不在本单。
|
||||
|
||||
PostgreSQL `length()` 按字节，与 BUG-464 相同。4,000 汉字正文 ≈ 12,000 字节，按字节撞 200,000 会早于「50 轮汉字」。上表 50 轮是任务书字符口径对照，不是汉字会话在线上能存到的轮数。物理上限 1,000,000 字节在这组夹具上仍晚于对话额度触发。
|
||||
|
||||
## 既有断言改动
|
||||
|
||||
| 文件 | 原值 | 新值 | 原因 |
|
||||
| --- | --- | --- | --- |
|
||||
| `database-local-business.test.ts` 迁移已应用列表 | 最末 `20260915010000_rectification_touch_chat_session.sql` | 另加 `20260916010000_consultation_session_capacity.sql` 及「不得复制进 db/migrations」 | 新迁移必须被 runner 应用到 |
|
||||
|
||||
未改幂等 / advisory lock / `session_missing` / 200 条满员三条既有用例。未改 `chat-session-authority.test.ts`（仍读 20260901010000 原文件，原文件未改）。
|
||||
|
||||
## 测试
|
||||
|
||||
| 命令 | 结果 |
|
||||
| --- | --- |
|
||||
| `./node_modules/.bin/tsc --noEmit` | 0 错 |
|
||||
| `npx tsx --test tests/consultation-session-capacity.test.ts` | 6 pass / 0 fail |
|
||||
| `npx tsx --test tests/consultation-*.test.ts tests/chat-session-*.test.ts` | 220 tests / 208 pass / **12 fail**：全部是 Windows `SKILL.md` symlink `EPERM`（`consultation-agentic-runtime`、`consultation-birth-time-mode`、`consultation-workflow-request` 整文件，以及 methodology 读 live skill 的 9 条）。与本单无关，既有环境缺口。本单 6 条与 `chat-session-*` 全绿 |
|
||||
| `npx eslint`（本单三个测试文件 `--max-warnings 0`） | 0 error / 0 warning |
|
||||
| `npm run lint` | **0 error** / 119 warning（既有，未动） |
|
||||
| `npm run db:migrate:check` | **blocked**：`SCHEMA_DATABASE_URL is required` |
|
||||
| `npm run test:db` | **blocked**：39 tests / 7 pass / 27 fail / 5 skip。失败均为 `spawnSync docker ENOENT` 或 Windows symlink EPERM。本单 `database-consultation-session-capacity` **skip**（`docker unavailable on this host`），不得写成通过 |
|
||||
| 全量 `npx tsx --test tests/*.test.ts` | 3089 tests / 3001 pass / 73 fail / 15 skip。失败为无 Docker `ENOENT`、Windows `SKILL.md` symlink `EPERM`、以及 `G:\\G:\\` 路径加倍，与既有环境缺口同类。本单 6 条静态合同在该套件里通过；DB 用例 skip |
|
||||
|
||||
## 收尾限制
|
||||
|
||||
- 运行时 Postgres 合同本机未跑。有 Docker 的验收机必须跑 `npm run test:db`。
|
||||
- 详情接口未分页。50 轮夹具 1.41 MiB，见 `BLOCKED.md`。
|
||||
@@ -240,7 +240,7 @@
|
||||
| `TASK-rectification-request-dossier-cache-20260915.md` | — | **低风险单，串行在 failure-attribution 之后（同改 `route.ts`）**：一轮 Agent 对话实测取 3.44 次整份 Case 档案（点选题 2.07 次），全仓约 40 个调用点、请求内零缓存；档案是「最近 50 轮 turns + 全部 evidence + 合成收据」的大 jsonb。做法是包装 `accounting` 客户端做**写即失效**的请求作用域缓存（两个只读投影命中缓存，其余任何 RPC 先清空再转发），**零调用点改动**。不得做成「请求内只读一次」——档案在请求内会变。BUG 段 726 | 待领取 | — |
|
||||
| `TASK-consultation-external-evidence-cache-20260915.md` | `PROGRESS-consultation-external-evidence-cache-20260915.md` | **普通聊天性能单（Python；2026-09-15 产品拍板改为排在 api-server-decomposition 之前）**：每轮每域同步等外网，cProfile 前三名全是 `api.vedastro.org` 的 HTTPS 往返（0.801 + 0.786 + 0.206 s），本地 swisseph 只有 0.022 s。三个护栏数字凑不齐：前台等 1.5 s、后台跑 8 s、线程池只有 2 个 worker，且超时**不 cancel** → 每 4 秒一轮就长期饱和，之后每轮白等再拿 `official_blocked`（BUG-727）。另 `western_evidence_packet` 122 KB 前端零读取点（BUG-728）。**产品定案**：按「出生数据+岁差+交点+UTC 日期」缓存（与引擎 `_official_snapshot_reference_date` 同键，否决自定 TTL），同日 0 等待 / 跨日先用旧的（≤7 天）后台刷新 / `daily_starlanguage` 要求当天 / 冷启动才走 1.5 s。**不许「干脆不调」——那会重开 BUG-301。** 另含 staging 单域耗时实测单（代码注释里的 21 s 与本机 0.5 s 差 40 倍，三域上限就是从它推的）。BUG 段 727–728 | 待验收 | `codex/consultation-external-evidence-cache-20260915` |
|
||||
| `TASK-consultation-context-memory-20260915.md` | `PROGRESS-consultation-context-memory-20260915.md` | **记忆三缺口（TS，可并行）**：历史超预算时从最老整轮丢弃，`droppedCount` 算了却**全仓零读取点**，模型不知道少看了几轮——单条截断有「省略 N 字」标记，整轮丢弃没有（BUG-729，BUG-555 防复发只写了「头部截断」所以漏网）；写摘要阈值写死 16,000，历史预算却是 `clamp((窗口−60k)×1.5, 4k, 40k)`，窗口 < **70,667** 时预算低于阈值 → 每轮静默丢（BUG-730，后台上架中等窗口模型即触发）；写满时服务端存着摘要，`continueInNewChat` 只带问题不带摘要，而 `context_summary` 根本不在任何会话接口的列里（BUG-731）。**产品定案：静默继承**，且摘要文本永远不许由客户端提供（`chatSessionCreateSchema` 只收来源会话 uuid）。BUG 段 729–731 | 待验收 | `codex/consultation-context-memory-20260915` |
|
||||
| `TASK-consultation-session-capacity-20260915.md` | — | **对话上限单（一份迁移，可并行；不碰 route.ts）**：`append_consultation_question` 的 200,000 字符额度里，`thinkingText`(≤4,000) + `thinkingSections`(实测 1,521/2,243/2,977) 占一半以上，而 `techniqueTruth`/`workflowReceipt`/`agentExecutionReceipt` 照样入库却不计入——同一条上限身兼二职且两职都没做好，约 **19 轮** 就「已写满」（200 条那档永远碰不到）。**产品定案：思考文本不计入**，额度只数用户读得到的正文（约 19 → 约 50 轮），另设一条按 `length(elem::text)` 把全部字段算全的物理上限（算式取 1,000,000，写进迁移注释）护住数据库行；两档都返回同一个 `session_full`。保留 advisory lock / 幂等 / 满员拒绝（BUG-464 防复发）。BUG 段 732 | 待领取 | — |
|
||||
| `TASK-consultation-session-capacity-20260915.md` | `PROGRESS-consultation-session-capacity-20260915.md` | **对话上限单（一份迁移，可并行；不碰 route.ts）**：`append_consultation_question` 的 200,000 字符额度里，`thinkingText`(≤4,000) + `thinkingSections`(实测 1,521/2,243/2,977) 占一半以上，而 `techniqueTruth`/`workflowReceipt`/`agentExecutionReceipt` 照样入库却不计入——同一条上限身兼二职且两职都没做好，约 **19 轮** 就「已写满」（200 条那档永远碰不到）。**产品定案：思考文本不计入**，额度只数用户读得到的正文（约 19 → 约 50 轮），另设一条按 `length(elem::text)` 把全部字段算全的物理上限（算式取 1,000,000，写进迁移注释）护住数据库行；两档都返回同一个 `session_full`。保留 advisory lock / 幂等 / 满员拒绝（BUG-464 防复发）。BUG 段 732 | 待验收 | `codex/consultation-session-capacity-20260915`（BUG-732）；`test:db` 环境缺口 |
|
||||
| `TASK-freeze-metric-change-20260915.md` | — | **规则单（后面两单的前置，无 BUG 号）**：两条增长冻结余量都用完（`page.tsx` 1,951/1,951 余 **0**；`jyotish_api_server.py` 11,334/11,363 余 **29**），冻结从「逼新代码往外走」退化成「拦路」。实证：`page.tsx` 行数砍 59% 但 `Home()` 的 `useState` 从 56 涨到 **66**（拆的是代码不是状态）；api server **225 个类方法只有 12 处真碰 HTTP 上下文**，4 处 `__new__` 伪造空壳就是这么来的。**产品拍板换口径**：主门改成「`Home()` 的 useState/useRef 不得增长」与「类方法数 + `__new__` 计数不得增长」，行数降级为粗护栏；**同时推翻 §6「参数式 hook 内部保持 0 个 React hook」**（那正是状态搬不走的原因）。改 `AGENTS.md` §6 + 两个合同测试，不碰业务代码 | 待领取 | — |
|
||||
| `TASK-home-state-lowering-20260915.md` | — | **page.tsx 状态下沉第一簇（串行在 freeze-metric-change + C2 + R3 之后）**：66 个 state 里 `rectification*` 占 **15** 个，而它们服务的 `<ConversationalBirthTimeRectification>` 本来就是 `dynamic()` 懒加载子树、挂着 24 个 props；`useRectificationSurface` 要解构约 56 个参数。把这簇搬进子树，`Home()` 的 useState 从 66 降到 ≤ 53。**零行为变化**；第一步必须先把 15 个逐个分类（只服务子树 / 外壳也要读）。产品否决了 Context Provider 与外部 store 两条路。不占 BUG 号 | 待领取 | — |
|
||||
| `TASK-rectification-engine-memoization-fix-20260915.md` | — | **验收修复单（只改测试，一行实现不许动）**：BUG-721 的实现**等价性成立**（我在改前 `6b3248bf` / 改后 `e4788dfc` 同机跑同一 payload，`candidate_scores` 逐字相同），9 条计数断言全过；但等价 golden 在本机复现不出来——4 处浮点尾数差（score 1.0e-4 ×2、`margin_percent` 1.1e-3 ×2）。**复发自 BUG-712**（「不得对全精度浮点做整体 `==`」，那一单只落在 ephemeris 一处）。而 `tests/test_rectification_*.py` 在 `CORE_PYTEST_TARGETS` 里，**staging 门禁靠机器舍入碰巧一致才是绿的**。修法：主证据换成**同进程差分**（把 static context 的四个缓存键置 `None` 即可回退旧路径，A/B 严格相等），golden 降为离散字段严格相等 + 浮点带容差（容差按实测 1.1e-3 推）；**禁止重建 golden 来「修」**。另含六份 golden 的仓库级排查。BUG-733 | 待领取 | — |
|
||||
|
||||
Reference in New Issue
Block a user