Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017eEAG8HD3mm8gsKXgk8uU8
3.9 KiB
3.9 KiB
TASK · sync6 合入后 staging 门禁仍红:「Frontend and database tests」中断(2026-10-07)
- 基线:
origin/staging@2df6ee72(sync6fb8277bf+ Claude 门禁补修)。staging 线上仍部署0ed45a4b。 - 对照:上一次绿的门禁 run 3206(
0ed45a4b)。 - 分支 / worktree:
codex/sync6-gate-red-20261007/.worktrees/sync6-gate-red-20261007(只有需要改代码时才建)。 - 执行方:产品负责人本机(有 Docker)。
- BUG 编号:开工时核对
docs/BUG_HISTORY.md最大号(写作时 BUG-1270)。
1. 事实
| run | 提交 | 结果 | 停在哪一步 |
|---|---|---|---|
| 3211 | fb8277bf |
failure | Python 快速门(扫描金样 D5/D11 未更新);后续步骤 skipped |
| 3213 | 2df6ee72 |
failure | 快速门、隐私扫描、Python 打包都通过;「Frontend and database tests」15:12:39 开始、15:28:17 失败;随后 lint 与 build 标 failure、用时 0 秒 |
| 3206 | 0ed45a4b |
success | 同一步只用 6 分半(07:12:48–07:19:15) |
run 3213 的网页日志(https://git.copse.top/root/Jyotisha/actions/runs/3213/jobs/6841/logs)只到 15:12:59:测试开跑 20 秒后再没有任何输出,没有失败名单,也没有 TAP 尾部摘要。运行机都是 xiaoxin(runner_id 11)。
Claude 在 Linux 上对 2df6ee72 的复核(无 Docker,数据库测试被跳过):
- Python 全量:62 条失败,与基线
5cc8e504逐名相同;快速门通过;隐私扫描 0 项。 - 前端
npm test:4990 项、失败 24,与基线逐名相同;tsc0;lint 0 error。 - 本轮前端改动只有测试与 fixture(scoring-11 版本字面量、跨午夜 fixture、扫描金样)以及
engine-client.ts一行默认版本号。数据库迁移用正则scoring-(9|[1-9][0-9]+)接受 scoring-11,没有写死 scoring-10。
2. 三种可能(按可能性排序)
- 运行机中途掉线:日志中断加上后续步骤「failure 0 秒」(正常失败是 skipped),更像 runner 失联后被 Gitea 判超时,与代码无关。
- 门禁上才会卡住的测试:只在有真实 PostgreSQL 时才跑的
database-*.test.ts,或某条测试在 CI 环境卡住;BUG-1254 的「10 分钟无槽位易手才判失败」与这次约 15 分钟的时长对得上。 - 内存或磁盘耗尽:运行机 OOM 时也会表现为日志中断。
3. 决策记录
产品 2026-10-07:Claude 出任务书,产品本机执行。不改 .gitea/workflows/**,不提升 main。
4. 步骤
| # | 做什么 | 判定 |
|---|---|---|
| S1 | 在 Gitea 网页对 run 3213 点「重新运行」(Re-run),这不改 workflow | 绿:判为可能 1,在 BUG 记录写 resolved(runner 偶发),然后做 S5。红:继续 S2 |
| S2 | 本机检出 2df6ee72,设 CI=1 跑 npm test --prefix frontend(会把完整 TAP 写到 frontend/gate-logs/frontend-tests.tap),记下总耗时,看有没有哪个文件超过 5 分钟 |
有失败或超时:记下测试名和报错原文,做 S3。全绿:做 S4 |
| S3 | 同样在 0ed45a4b 上跑 S2,对比两边的失败名单与耗时 |
只有 2df6ee72 失败的才算本轮引入。按 AGENTS §5 写 BUG(报错原文、触发条件、根因),在分支上修复,写三栏,推 staging |
| S4 | 门禁机排查:让管理员看 xiaoxin 在 15:12–15:28(UTC)的 runner 日志、内存(OOM killer)与磁盘 |
写进 docs/research/pre_work_error_ledger.md(ERR 编号顺延),附证据 |
| S5 | 门禁绿后核对部署 | https://staging.jyotisha.chat/api/health 的 deployment.gitCommit = 最近一次含门禁路径改动的 staging 提交;/login 200;未登录 /api/account 401 |
5. 记录
docs/BUG_HISTORY.md(新编号;若是 runner 偶发,关联 BUG-1254、BUG-266)、docs/tasks/README.md 状态板。日志里不要贴密钥或令牌。
6. 让步
S4 可以延后,S1、S5 不让步。