服务器长跑不再堆积取消监听，数据库少走几趟。
报告工人的等待到点就摘掉取消监听。本地数据库缓存表结构，并把设置身份合成一条语句，对照通过后默认打开，写成 off 仍走原来的语句。交付、重算和限流的内存表会过期。登录读缓存默认关闭，要开再设 IDENTITY_SESSION_COOKIE_CACHE=on。 自测：tsc 通过，lint 0 error，点名测试 134 通过，test:db 开关关和开都只有已知的 13 条失败，往返 49 降到 32。 Co-Authored-By: Grok (agent loop)
This commit is contained in:
jesse-ux
co-authored by
Grok (agent loop)
Grok (agent loop)
parent
66cd60081f
commit
4c3485bc23
@@ -17795,3 +17795,63 @@
|
||||
- 复发自：无。
|
||||
- 修复版本：未修复。
|
||||
|
||||
## BUG-1326 | 个人报告工人空转时，取消监听一直留在进程上
|
||||
|
||||
- 状态：resolved（代码+回归测试），生产内存曲线待部署后观察
|
||||
- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
|
||||
- 来源：issue #58。任务书 T1。
|
||||
- 现象：报告工人长时间没有活干时，进程内存逐日上涨。取消这次工人时，之前每一次等待都还挂着一个取消监听。
|
||||
- 触发条件：工人循环用进程级取消信号，两次领任务之间按间隔等待。等待到点之后监听不摘。
|
||||
- 根因：等待用了「只触发一次」的取消监听。这个选项只在真的取消时摘掉监听。计时器自己到点时，监听还留在信号上。信号活得和进程一样长，监听就一直积着。
|
||||
- 修复：计时器到点时先摘掉监听再结束等待；真的取消时清掉计时器并结束等待。已经取消的信号仍立刻返回。计时器仍不挡住进程退出。引导打分里同一写法的等待也改成到点摘监听。
|
||||
- 验证：`frontend/tests/personal-report-worker-sleep-listener.test.ts` 4 通过。空转和抛错各 200 次后，取消前监听数是 0，取消后循环马上结束。修之前的同形等待在第 200 次时留下 199 个监听（断言 `199 !== 0`）。
|
||||
- 防复发：上述测试锁住「200 次之后监听数为 0」。
|
||||
- 相关记录：BUG-1328。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/node-runtime-resources-20261013`，尚未合入 staging。
|
||||
|
||||
## BUG-1327 | 本地数据库每一问都重复查表结构和设置身份
|
||||
|
||||
- 状态：resolved（代码+回归测试）。2026-10-14 对照通过后，两个开关默认打开。
|
||||
- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
|
||||
- 来源：issue #58。任务书 T2。
|
||||
- 现象：同一次页面操作里，本地数据库要来回很多趟。表有哪些列、主键是什么、函数怎么调用，每次都现查。设置身份也要单独走一趟。
|
||||
- 触发条件：网页通过本地 Postgres 适配层读写真业务表。
|
||||
- 根因：元数据没有进程内缓存。设置角色和两条身份参数各是一条语句。事务的开始和提交仍各走一趟，这是故意留下的。
|
||||
- 修复：`JYOTISHA_PG_METADATA_CACHE` 缓存列类型、主键和函数签名，300 秒过期；缓存键带连接串，列和函数再带角色。不缓存空结果，也不缓存「函数不存在」。业务语句报列、表、函数或类型不匹配时，清掉该连接串的全部元数据并照旧返回错误，不自动重试。关掉某个连接或全部连接时，对应元数据一起清掉。`JYOTISHA_PG_MERGED_SESSION_SETUP` 把设置角色和两条身份合成一条参数化语句。角色仍只允许既有的两个业务角色。开始和提交不并进这条语句。两个开关都写成 `off` 时，语句顺序与改前一致。未设置或 `on` 为打开。只读且没有身份时省掉事务的做法已否决：那会把角色留在连接上，还回池子后可能给下一个请求。
|
||||
- 验证：不连数据库的往返单测锁住关闭时 6 条、打开且命中缓存时 4 条。真库测试确认事务内身份生效，连接归还后再借出时身份已空。对照脚本第二次（带三组原始数）整段往返 49 降到 32，耗时中位数 75.84 毫秒降到 36.48 毫秒，返回内容逐字节一致。第一次同样是 49 降到 32。`npm run test:db` 两轮都是 81 项、通过 68、失败 13、取消 0。失败名称与 Windows 已知清单逐条相同，没有多出来的。
|
||||
- 防复发：往返单测锁住关闭时的语句顺序，以及角色、参数名、报错、过期和关闭连接都会让缓存失效。
|
||||
- 相关记录：BUG-166、BUG-578、BUG-596、BUG-926。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/node-runtime-resources-20261013`，尚未合入 staging。
|
||||
|
||||
## BUG-1328 | 三张只进不出的内存表会随运行变大
|
||||
|
||||
- 状态：resolved
|
||||
- 首次发现 / 最近更新：2026-10-13 / 2026-10-14
|
||||
- 来源：issue #58。任务书 T3。
|
||||
- 现象：校正交付去重、重算尝试和请求限流各有一张进程内的表。旧条目读的时候已经不算数，却不删除，进程活得越久表越大。
|
||||
- 触发条件：长时间有人做校正或调用限流接口。
|
||||
- 根因：写入只增加，没有过期清理，也没有条数上限。
|
||||
- 修复：交付记录超过 60 秒就删，最多留 1 万条。重算记录改存时间，超过 6 小时就删，最多留 5 千条。限流按本进程见过的最大窗口定期删掉已经出窗的键；1 小时窗口的键不会在 61 秒时被删。限流的对外类型不变，调用方仍可传入自己的表。
|
||||
- 验证：交付、重算、限流的新测试通过。窗口内的允许或拒绝与原来的断言一致，没有改旧断言。同一道校正题在 6 小时内仍不会重算第二次；超过 6 小时或被挤出后可能再算一次，这比「进程一重启就可能再算」更收敛。
|
||||
- 防复发：硬上限和过期都有测试。1 小时窗口的键在短窗口清理后必须还在。
|
||||
- 相关记录：BUG-1326。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/node-runtime-resources-20261013`，尚未合入 staging。
|
||||
|
||||
## BUG-1346 | 每次带登录的请求都重新读一次会话
|
||||
|
||||
- 状态：resolved（代码+回归测试）。开关默认关闭：查库次数已下降，真实身份库的耗时对照还没做，未达到默认打开的门槛。
|
||||
- 首次发现 / 最近更新：2026-10-14 / 2026-10-14
|
||||
- 来源：issue #58。产品负责人 2026-10-14 决定可以开。任务书 T6。
|
||||
- 现象：每个已登录请求都到身份库读一次会话。
|
||||
- 触发条件：用户端 Better Auth 配置没有会话读缓存。后台没有另一份登录配置。
|
||||
- 根因：用户端会话配置未启用 `cookieCache`。
|
||||
- 修复：只有环境变量 `IDENTITY_SESSION_COOKIE_CACHE` 精确等于 `on` 时，用户端会话才缓存 300 秒。未设置或其它值与现在一样，每次读库。改密码、注销账户、以及全部后台入口每次都跳过缓存。改邮箱、两步验证和后台插件自带的敏感入口本来就会重新读库，这次没有改它们。咨询里的注销检查和后台的封禁检查仍每次查库。会话能活多久、改密码后是否作废、Cookie 的安全属性、表结构都没改。代价：缓存打开后，一台设备改了密码，其它设备上的旧登录最多还能再浏览 300 秒，这段时间做不了改密码和注销。
|
||||
- 验证：`frontend/tests/identity-session-cookie-cache.test.ts` 4 通过。缓存打开时连续 3 次普通读取只查会话 1 次，敏感读取每次都查；缓存关闭时 3 次都查。会话被清掉后，敏感读取立即无效，普通读取在 300 秒内仍有效，超过后无效。
|
||||
- 防复发：上述测试锁住开关关闭时不出现缓存配置，以及 300 秒后普通读取失效。
|
||||
- 相关记录：BUG-1327。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/node-runtime-resources-20261013`，尚未合入 staging。
|
||||
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
# 进度 · 服务器内存与数据库往返（2026-10-13）
|
||||
|
||||
issue #58。分支 `codex/node-runtime-resources-20261013`。
|
||||
|
||||
任务书基线写的是 `77057a819`，计划评论里的基线是 `2994588ad4d858dead4835943e5883c5aa2b03f8`。本分支实际从当时的 `origin/staging` `66cd60081f37a57680274633fcb3fb942d01bb2f` 拉出。没有因此停下来问产品，改动仍按任务书做。
|
||||
|
||||
## 做了什么
|
||||
|
||||
- 报告工人的等待：计时器到点就摘掉取消监听。引导打分里同一段等待也摘掉。空转不再往进程上堆监听。
|
||||
- 本地数据库：列、主键、函数签名缓存 300 秒；设置角色和两条身份合成一条语句。开始和提交仍分开。两个开关默认打开，写成 `off` 时语句顺序与改前一致。
|
||||
- 三张内存表：交付记录超过 60 秒删除，最多 1 万条；重算记录超过 6 小时删除，最多 5 千条；限流按见过的最大窗口清理已出窗的键。
|
||||
- 登录读缓存：只有 `IDENTITY_SESSION_COOKIE_CACHE=on` 才缓存 300 秒。默认关闭。
|
||||
|
||||
## 不做的
|
||||
|
||||
只读、又没有身份时省掉事务：不做。那种做法只能用会话级角色，归还连接前再清。往返数不降，而且一旦没清掉，下一次请求会带着上一次的角色。违反「连接还回池子时不能带着角色或身份」。
|
||||
|
||||
`begin` 没有并进一条多语句查询。
|
||||
|
||||
## 语义变化
|
||||
|
||||
同一道校正题、同一份证据，6 小时后或因为超过 5 千条被挤出后，可能再重算一次。这比「进程重启后才会再算」更收敛。60 秒内的交付去重、窗口内的限流允许或拒绝，都没有改。
|
||||
|
||||
## 基线失败
|
||||
|
||||
修之前的等待写法，在第 200 次空转时取消信号上还有 199 个监听。同形脚本输出：`listenersAt200=199`，`assertion failed: 199 !== 0`。修之后的测试断言是 0，并且通过。
|
||||
|
||||
## 登录读取的调用点
|
||||
|
||||
敏感，每次跳过缓存：
|
||||
|
||||
- 改密码：`frontend/src/app/api/account/password/route.ts`
|
||||
- 注销账户：`frontend/src/app/api/account/deletion/route.ts`
|
||||
- 全部后台入口：`frontend/src/lib/admin/auth.ts`
|
||||
|
||||
其余业务接口走 `createServerSupabaseClient()`，不带跳过参数。开关打开后，这些普通读取可以走 300 秒缓存。
|
||||
|
||||
改邮箱、两步验证、后台插件自带的敏感入口本来就会重新读库，这次没改。咨询里检查「正在注销」的那次调用，以及后台查封禁的语句，都没有改成缓存。
|
||||
|
||||
## 对照结论
|
||||
|
||||
详见 `docs/testing/node-runtime-resources-ab-20261013.md`。两个数据库开关一起：往返 49 → 32（低于 70%），耗时中位数 75.84 → 36.48 毫秒（下降 51.9%），返回内容一致。`npm run test:db` 开关关、开关开各一轮，都是 81 项、通过 68、失败 13、取消 0。失败名称与 `tools/agent-loop/windows-known-failures.txt` 的 13 条相同，没有多出来的。运行器因此退出码是 1，这 13 条是 Windows 上原有的。两个数据库开关默认打开。
|
||||
|
||||
登录读缓存的查库次数在测试里从 3 降到 1，但没有对真实身份库做耗时对照，默认保持关闭。要打开，把 `IDENTITY_SESSION_COOKIE_CACHE` 设成 `on`。
|
||||
|
||||
网页容器已经用 env 文件读环境变量，所以这三个名字不必改 Compose。
|
||||
|
||||
## 自测
|
||||
|
||||
| 检查 | 命令 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 类型 | `tsc --noEmit -p frontend` | 通过，退出码 0 |
|
||||
| 规范 | `npm run lint`（在 frontend） | 0 error，125 条原有 warning，未改 |
|
||||
| 本单测试 | `tsx --test` 任务书点名的文件加登录缓存测试 | 134 通过，0 失败，0 取消 |
|
||||
| 真库身份 | `database-local-postgres-session-setup.test.ts` | 1 通过。事务内角色和身份生效，连接归还后再借出时身份已空 |
|
||||
| 数据库套件 | `npm run test:db`，两开关先关后开 | 各 81 / 通过 68 / 失败 13 / 取消 0，名称与已知清单一致 |
|
||||
| 往返对照 | `scripts/bench-local-pg-roundtrips.ts` | 见上，`payloadMismatch` false |
|
||||
|
||||
没有跑前端全量 `npm test`、Python 快速门、`next build`。生产内存曲线要等部署后看。真机两台设备改密码的步骤在 `docs/testing/node-runtime-resources-20261013.md`，登录缓存默认关着，那份清单的第 2 步要先把开关打开才看得到。
|
||||
@@ -468,7 +468,7 @@
|
||||
| 任务书 | 进度 | 主题 | 状态 | 落点 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `TASK-rect-scoring-perf-20261013.md` | — | 校正打分提速：引导窗口平方扫描、候选不变量重复算、响应带无读取点字段、候选数上限 241（BUG-1323～1325、1345） | 待领取 | `codex/rect-scoring-perf-20261013` |
|
||||
| `TASK-node-runtime-resources-20261013.md` | — | 报告 worker abort 监听泄漏、本地 PG 适配层往返与元数据缓存、无上限内存表、用户端会话读缓存（BUG-1326～1328、1346，PG 与缓存部分 A/B） | 待领取 | `codex/node-runtime-resources-20261013` |
|
||||
| `TASK-node-runtime-resources-20261013.md` | `PROGRESS-node-runtime-resources-20261013.md` | 报告 worker abort 监听泄漏、本地 PG 适配层往返与元数据缓存、无上限内存表、用户端会话读缓存（BUG-1326～1328、1346，PG 与缓存部分 A/B） | 待验收 | `codex/node-runtime-resources-20261013` |
|
||||
| `TASK-home-sidebar-rerender-20261013.md` | — | 流式回答时侧栏每帧整栏重渲染（BUG-1329，A/B） | 待领取 | `codex/home-sidebar-rerender-20261013` |
|
||||
| `TASK-api-disk-cache-retention-20261013.md` | — | API 磁盘缓存只进不出、VedAstro 审计文件留存出生资料、失败快照久缓存、缓存键规范化（BUG-1330～1332，A/B） | 待领取 | `codex/api-disk-cache-retention-20261013` |
|
||||
| `TASK-report-reference-perf-20261013.md` | — | 长报告出稿提速：术语替换命中预检、哈希单次遍历、同盘复用（BUG-1335～1336，A/B） | 待领取 | `codex/report-reference-perf-20261013` |
|
||||
|
||||
@@ -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/scripts/bench-local-pg-roundtrips.ts`。库是测试用的临时 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