合并 staging，并让发问准备的检查跟上新位置
两条按源码原文查找的检查改认搬走后的写法，意思没有放宽。对照脚本挪到测试目录，镜像构建不再去找测试文件。业务代码和三个开关的默认值没改。 自测：相关前端测试 40 通过，失败 0，取消 0。假时钟仍是并行 160、串行 210。tsc 0 错，lint 0 error。 Co-Authored-By: Grok (agent loop)
This commit is contained in:
jesse-ux
@@ -0,0 +1,66 @@
|
||||
# 磁盘缓存留存 A/B（2026-10-14）
|
||||
|
||||
对照的是本分支的父提交 `66cd60081f37a57680274633fcb3fb942d01bb2f`（建分支时的 `origin/staging`）。任务书里写的 `77057a819` 已经不是当前测试线头。A 用 `git show` 把父提交的接口文件载入同一进程，并把它的仓库路径指回本工作树，否则临时副本找不到引擎。B 是本分支。
|
||||
|
||||
演练用虚构盘，不写真实出生资料。文件都在系统临时目录，不写工作树里的 `scratch/`。
|
||||
|
||||
主测量挡住了 `jhora` 和 `vedastro` 的导入。本机装了 VedAstro SDK，并且能连上官方端口；另有一组不挡 SDK、但仍关闭外网取数，见文末。
|
||||
|
||||
## 命令
|
||||
|
||||
```powershell
|
||||
.venv\Scripts\python.exe scripts\research\api_chart_cache_byte_diff.py
|
||||
.venv\Scripts\python.exe scripts\research\api_disk_cache_ab.py
|
||||
.venv\Scripts\python.exe scripts\research\api_disk_cache_ab.py --with-sdk --sdk-probe
|
||||
```
|
||||
|
||||
## 命中率
|
||||
|
||||
20 张虚构盘 × 3 种写法 × 快速/完整 × 7 天 × 每种重复 3 次 = 2520 次取键。取键用的是真实缓存键函数，没有把 2520 次都做成完整排盘。
|
||||
|
||||
| | 改前 A | 改后 B | 变化 |
|
||||
| --- | --- | --- | --- |
|
||||
| 不同缓存键 | 840 | 280 | 少 560 |
|
||||
| 命中次数 | 1680 | 2240 | 多 560 |
|
||||
| 命中率 | 0.6667 | 0.8889 | B / A = 1.333 |
|
||||
|
||||
目标是混合写法下 B 至少为 A 的 2.5 倍。按任务书规定的「重复 3 次」算，没有达到：A 自己靠重复就已经有三分之二命中，写法合并只能再抬到约 89%。若不算这 3 次重复、只看三种写法各问一次，A 的命中率是 0，B 是 0.6667。目标数字不改。
|
||||
|
||||
## 七天后的文件
|
||||
|
||||
留存演练写的是短记录，用来数文件，不是完整盘面。期限 900 秒，只有当天的键还没过期。
|
||||
|
||||
| | 改前 A | 改后 B |
|
||||
| --- | --- | --- |
|
||||
| 清理前文件数 | 840 | 280 |
|
||||
| 清理前字节 | 109200 | 36400 |
|
||||
| 清理后文件数 | 840（旧代码没有这份清理） | 40 |
|
||||
| 当天仍有效的键 | 120 | 40 |
|
||||
|
||||
B 清理后的文件数等于当天有效键数，达到「不超过当天活跃键」的目标。
|
||||
|
||||
审计文件：B 在默认关闭时写出 0 个。达到目标。
|
||||
|
||||
负缓存：种入当天和前一天各一份，清理后剩 1 份（当天）。达到目标。
|
||||
|
||||
## 清理耗时
|
||||
|
||||
| 场景 | 结果 |
|
||||
| --- | --- |
|
||||
| 预置 10000 个已过期排盘缓存后，整次清理 | 20.174 秒，排盘目录 20170.902 毫秒，删掉 10000，剩下 0 |
|
||||
| 上面七天演练里的排盘目录 | 370.161 毫秒 |
|
||||
|
||||
目标是 10000 个文件在 2 秒内、且不在请求线程。本次在后台函数里测，不在请求线程；耗时没有进 2 秒。这是 Windows 上逐个读文件再删除的实测，目标不改。默认清理间隔仍是 1800 秒，失败快照短期限仍是 300 秒，不因为这次没进 2 秒就改默认值。
|
||||
|
||||
## 排盘耗时（一次虚构盘，快速排盘，外网关闭）
|
||||
|
||||
| | 中位数 |
|
||||
| --- | --- |
|
||||
| 未命中 3 次 | 23.036 毫秒 |
|
||||
| 命中 3 次 | 5.249 毫秒 |
|
||||
|
||||
## 响应是否还是同一张盘
|
||||
|
||||
数值等价的写法（小时 12 / 12.0 / "12"，纬度数字和字符串，时区 5.5 和 "5.5"，秒缺省和 0）在快速排盘下去掉 `runtime_cache` 后逐字节相同。完整排盘只差官方快照缓存上的写入时刻和到期时刻，盘面没有别的差异。父提交和本分支对同一张快速排盘、去掉 `runtime_cache` 后逐字节相同。因此这些字段可以合并进同一把缓存键。
|
||||
|
||||
不挡 SDK 的一组：本机有 VedAstro SDK，官方端口能连通。探针仍关闭外网取数。一次完整排盘 4.167 秒，没有报错。没有拉取真实快照。
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## 进程内假时钟
|
||||
|
||||
命令：`node node_modules/tsx/dist/cli.mjs scripts/research/consult-prep-parallel-ab.mts`（在 `frontend` 目录）。
|
||||
命令：`node node_modules/tsx/dist/cli.mjs tests/consult-prep-parallel-ab.mts`（在 `frontend` 目录）。
|
||||
|
||||
假延迟：注销检查 50 毫秒，读会话 80 毫秒，解析模型 80 毫秒。这不是数据库实测。
|
||||
|
||||
|
||||
@@ -0,0 +1,12 @@
|
||||
# 真机走查 · 回答生成时侧栏不再跟着闪（BUG-1329，issue #59）
|
||||
|
||||
浏览器 A/B 未跑。部署到 staging 后，在 `https://staging.jyotisha.chat` 登录一个没有真实会话内容需要露出的账号，按顺序看：
|
||||
|
||||
1. 电脑浏览器打开首页。左侧会话列表的样子、顺序、分组和以前一样。
|
||||
2. 发一个普通问题，等回答一个字一个字出来。这段时间左侧列表不跟着闪、不跟着整栏重画。回答本身仍是逐字出现。
|
||||
3. 回答过程中点另一条会话，能打开那一条。点当前这条的菜单，改名、置顶、分享、删除仍可用，改的是刚刚点的那一条。
|
||||
4. 右上角账户菜单仍能打开资料、通用、账单和退出。
|
||||
5. 换一个人物后，左侧列表换成那个人的会话，不串到别人的。
|
||||
6. 手机宽度再看一遍第 2 步。侧栏抽屉的开关和以前一样。
|
||||
|
||||
任何一步不对，在 issue #59 里写是哪一步、哪台设备，并把标签改回 `agent/待规划`。不要贴出真实会话内容。
|
||||
@@ -0,0 +1,18 @@
|
||||
# A/B · 回答生成时侧栏重画（BUG-1329，issue #59）
|
||||
|
||||
同一测试 `frontend/tests/home-sidebar-rerender.test.tsx`，同一输入。A 是改代码前的 `66cd60081f37a57680274633fcb3fb942d01bb2f`（任务书写的 `77057a819` 已被后续提交盖过）。B 是分支 `codex/home-sidebar-rerender-20261013`。各跑 3 次。会话都是虚构的「Synthetic session N」。没有真实会话内容。
|
||||
|
||||
度量是 60 帧里的注册次数、侧栏提交次数、这 60 帧的 Profiler 耗时合计。内容用剔除函数字段后的 SHA-256 比较。
|
||||
|
||||
| 档 | A 注册 / 提交 / 耗时中位 | B 注册 / 提交 / 耗时中位 | 内容 |
|
||||
| --- | --- | --- | --- |
|
||||
| 30 条 | 60 / 60 / 2778.961 毫秒 | 0 / 0 / 0 | 两边都是 `b18f05a3d83be5b41584787b7c0495f1fcec8ef7b8ecfbdbb3c083c40796c103` |
|
||||
| 100 条 | 60 / 60 / 11799.253 毫秒 | 0 / 0 / 0 | 两边都是 `cef0a63d6f3fe72e541f9ac882b8eaf305b6933fdd07ca3002e8cd03bb139d25` |
|
||||
|
||||
A 的三次 30 条耗时：2774.964、2778.961、4202.085。100 条：10530.828、11799.253、12284.103。B 的三次都是 0。
|
||||
|
||||
正确性：换当前项后 B 注册 1 次，外壳看到新的当前项。改一行标题后标题更新。换成另一人的会话后列表换掉。只改回调版本不再注册，点「打开会话」和「改名」记到的都是第 4 版。A 在只改回调版本时还会再注册 1 次；B 不注册，但调用结果相同。
|
||||
|
||||
判定：B 在 60 帧内注册 0、侧栏提交 0，内容摘要一致，`session-list-lifecycle` 全绿。可以交付。
|
||||
|
||||
浏览器 A/B 未跑。
|
||||
@@ -0,0 +1,13 @@
|
||||
# 真机清单 · 登录缓存与长时间运行（2026-10-13）
|
||||
|
||||
对应 BUG-1326、BUG-1346。在 staging 上用两个浏览器（或一台电脑、一台手机）登录同一个测试账号。不要把账号、口令或页面原文记进仓库。
|
||||
|
||||
本轮代码里，登录读缓存默认关闭。要做下面第 2–4 步，服务器环境变量 `IDENTITY_SESSION_COOKIE_CACHE` 必须是 `on`。未设置或其它值时，改密码后另一台设备会马上要求重新登录，第 2 步不会出现「还能浏览大约 5 分钟」。
|
||||
|
||||
| 步 | 怎么做 | 通过标准 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 两台设备都登录，各自打开首页并翻一两页 | 都能正常看到自己的会话，不要求反复登录 |
|
||||
| 2 | 设备 A 修改密码。5 分钟内用设备 B 只浏览首页、会话列表和星盘，不要改密码、不要注销 | 设备 B 在这 5 分钟里仍能浏览 |
|
||||
| 3 | 仍在这 5 分钟内，用设备 B 尝试修改密码或申请注销账户 | 被拒绝，不能拿旧登录做这两件事 |
|
||||
| 4 | 等到改密码已超过 5 分钟，再用设备 B 刷新 | 被要求重新登录 |
|
||||
| 5 | 用新密码在设备 B 重新登录，再浏览一次 | 能进入，会话列表还在 |
|
||||
@@ -0,0 +1,21 @@
|
||||
# 本地数据库往返对照（2026-10-14）
|
||||
|
||||
环境：Windows，Docker 29.8.0，Node v22.23.2。脚本 `frontend/tests/bench-local-pg-roundtrips.ts`（2026-10-14 按修复单从 `frontend/scripts/` 挪来，数字未重跑）。库是测试用的临时 Postgres，数据是虚构用户。每组 50 遍，重复 3 组，先各热身 1 遍。往返数是每组平均值的中位数。耗时中位数是三组中位数的中位数。p95 是全部 150 遍的单遍耗时。
|
||||
|
||||
判定用第二次运行（输出里带三组原始数）。第一次运行同样是 49 降到 32，中位数 89.51 毫秒降到 32.70 毫秒，内容一致，方向相同。
|
||||
|
||||
| 模式 | 开关 | 往返 | 中位数（毫秒） | p95（毫秒） | 三组（往返 / 中位数毫秒） |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| A | 两个都关 | 49 | 75.84 | 88.25 | 49 / 82.51；49 / 75.84；49 / 73.81 |
|
||||
| B | 两个都开 | 32 | 36.48 | 39.47 | 32 / 36.66；32 / 36.48；32 / 35.71 |
|
||||
| B1 | 只开元数据缓存 | 40 | 40.54 | 44.37 | 40 / 41.56；40 / 40.54；40 / 39.86 |
|
||||
| B2 | 只开合并身份设置 | 41 | 67.83 | 72.75 | 41 / 68.46；41 / 66.47；41 / 67.83 |
|
||||
|
||||
- 往返：32 ≤ 49 的 70%（34.3）。通过。
|
||||
- 耗时：下降 (75.84 − 36.48) / 75.84 = 51.9%，不低于 15%。通过。
|
||||
- 四种模式的业务返回逐字节一致（`payloadMismatch` 为 false）。通过。
|
||||
- 只开其中一个时，往返都还高于 70% 那一刀；只合并身份设置时，这一次耗时只降了约 10.6%。两个一起才过门槛，所以两个都默认打开。写成 `off` 仍走改前的语句顺序。
|
||||
|
||||
登录读缓存没有放进这次真库计时。内存里的登录测试看到普通读取的查库次数从 3 降到 1，但那不是身份库的耗时对照，所以 `IDENTITY_SESSION_COOKIE_CACHE` 保持默认关闭。
|
||||
|
||||
`npm run test:db` 两轮都是 81 项、通过 68、失败 13、取消 0。失败名称与 `tools/agent-loop/windows-known-failures.txt` 的 13 条逐条相同，没有多出来的。因此两个数据库开关默认打开。
|
||||
Reference in New Issue
Block a user