  q792602257andClaude Opus 5
|
3284e086ad
|
feat(trading): 浏览器掉线兜底——任务边界自愈重建，中途掉线转 needs_human
SiteInteractor 的 Chromium 是进程级单例，此前启动后即假定永远活着：全仓唯一的
is_connected() 探活在 scraping 侧，交易侧既不探活也不重启。容器里 Chromium 崩溃
是有真实前提的（/dev/shm 不足、OOM kill、seccomp 挡 sandbox，docker-compose.yml
里已有相关注释），一旦发生，进程还活着但之后每一单都会失败，且 /health 恒返回
ok，restart: unless-stopped 永远不会被触发。
更隐蔽的一条：clear_cart / enter_checkout / pay 等处的 new_page()、context.request
写在 try 之外，掉线抛的 TargetClosedError 不是 AppError，会穿过 runner 的
except AppError 落到主循环那个只记日志的兜底里——任务一次都不上报，网关侧要干等
整个 lease_ttl（默认 300s）才被 sweep 置 stale。clear_cart 是 execute() 的 step 0，
浏览器死时最先撞上的正是它。
分三层处理：
- 任务边界自愈。_launch() 从 start() 抽出，_context_options() 统一 context 参数
（重建必须与启动完全一致，指纹漂移就是一次风控事件）；_refresh_context_if_stale
改名 _ensure_context_ready()，先探活重建再做原有的 storage_state mtime 检查
（顺序不可换，mtime 重建要用 self._browser）。重建前丢弃 _checkout_pages 里的
残留确认页并记 warning——那些 Page 已随浏览器一起没了。
- 中途掉线不重建，抛 BrowserDeadError（新增，5006）。新增 _new_page() 与
_request() 两个壳收口裸异常；_request() 只在确认浏览器真死了时才改写异常，
站点 5xx 这类正常业务失败原样抛出。submit_order / pay 入口用
_require_live_browser() 直接拒绝：这两步复用 enter_checkout 留存的 Page，
重建救不回服务端订单草稿，而 pay 跑的时候订单已经真的提交了。顺带修掉一个
误诊——浏览器死时 submit_order 原先报「未找到确认按钮」，把「浏览器崩了」
说成「站点改版了」，两者的处置方式完全不同。
- runner 把 BrowserDeadError 转 needs_human 而非 failed，except 分支排在
except AppError 之前（子类，顺序反了就报 failed）。掉线发生在动作中途，
站点侧生效与否无从判断，不能给上游「明确失败」的结论。
/health 暴露 browser 状态，掉线时 degraded + HTTP 503 + code 5006，让
Dockerfile.trading 的 HEALTHCHECK 探到并重启容器。重启不会导致重复下单：网关侧
任务绝不自动重投，租约过期只置 stale 等人工 reclaim（docs/order-gateway.md §5），
重启只是恢复领新任务的能力。启动窗口期 started=False 不算掉线。
README 错误码表补 5005（此前遗漏）与 5006。
新增 15 个用例覆盖探活三态、is_connected() 自身抛错、边界重建/不重建/丢弃残留页/
重建失败、两个包装壳的分支、submit/pay 拒绝、runner 转 needs_human、/health 503。
真实 Chromium 崩溃无法在离线测试里制造，用例模拟的是 is_connected() 返回 False
这个唯一可观测信号，覆盖的是代码对该信号的反应而非崩溃本身；容器 HEALTHCHECK
真的触发重启这条链路尚未实跑验证。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-20 16:01:47 +08:00 |
|
|
q792602257
|
912e10086f
|
fix(docker): 为容器内 rakuten 用户建 home 目录,修复 Chromium 启动 SIGTRAP
rakuten 用户是 useradd --no-create-home 建的,HOME 指向不存在的目录。
Chromium 启动时要写 $HOME/.config、~/.pki,写不了就 CHECK 失败触发
int3(SIGTRAP)自杀,Playwright 侧表现为 BrowserType.launch: Target closed。
- Dockerfile / Dockerfile.trading:ENV 增加 HOME=/home/rakuten,
mkdir + chown 补上 /home/rakuten
- 抓取镜像同样修:浏览器兜底(browser_fallback)也是非 root 跑 Chromium,
属同一隐患
实测验证:docker run 加 -e HOME=/tmp 后 chrome 可正常 --dump-dom 输出
|
2026-08-16 20:59:28 +08:00 |
|
|
q792602257andClaude Opus 5
|
63c41b61e7
|
自动登录接口 + 有状态端容器化部署 + 三服务合并 openapi 导出
自动登录（此前只能人工跑 scripts/login.py 再 /api/auth/reload）：
- 新增 POST /api/auth/login：动作顺序与下单前的 require_logged_in 一致（探测 →
未登录则按 account.yaml 登一次 → 再探测），已登录直接跳过不白起浏览器。
刻意**不抛 5001**：失败以 logged_in=false + 各站 detail 正常返回，调用方自己
决定是人工接管还是换账号。
- 新增 RAKUTEN_AUTO_LOGIN_ON_START（默认 false）：启动即准备登录态，为容器部署
而存在（镜像里没有落盘的 storage_state）。做成后台任务而非启动阻塞——登录最长
等 relogin_timeout_seconds（默认 300s，撞验证码时在等人工），阻塞会让 /health
在这段时间里连端口都不通；关服务时 cancel 掉在途的那次。
- 自动登录不绕过站点校验：凭据是用户自己配在 account.yaml 里的，代填进站点自己的
登录表单，撞 reCAPTCHA / 设备验证会停在有头浏览器等人工，等不到就超时失败。
容器化部署（新增 Dockerfile.trading + docker-compose.yml）：
- 有状态端单独出镜像不是为了整洁：下单/结算必须用**有头** Chromium（headless 会让
结算 SPA 失灵），镜像要带 Xvfb + 日文字体 + 给人工接管用的可选 x11vnc，抓取镜像
没有这些。网关复用同一镜像只换 command。
- Jenkinsfile 一条流水线产出两个镜像，BUILD_SCRAPING / BUILD_TRADING 两个开关控制。
- .dockerignore 补上 account.yaml / .auth/ / .browser-data/ / data/：明文密码+卡号、
可直接冒充账号的 cookie、带登录态的浏览器 profile、含真实 PII 的证据快照，都不该
进镜像也不该进 build context，运行时一律走挂载。
- .env.example 里 RAKUTEN_AUTO_LOGIN_ON_START 刻意留成注释：compose 的变量插值与
env_file 读的是同一个 ./.env，这里写成显式值会让 compose 的 `${...:-true}` 失效，
按 compose 文件头「cp .env.example .env」走反而不会自动登录。
openapi 导出（scripts/export_openapi.py）：三服务合并成一份可直接导入 Apifox /
Postman 的文档，每条接口带 operation 级 servers（不必手动切端口）。鉴权标注是遍历
FastAPI 依赖树认出真的挂了 require_bearer_token 的接口，不按路径猜。
openapi.json 本身仍是 gitignore 的本地生成物，因此 tests/test_openapi_export.py
只在内存里校验合并逻辑（三服务覆盖、operation 级 servers、除 /health 外全部标鉴权、
operationId 唯一、$ref 可解析），不断言「文件内容 == 当前导出结果」——CI 的全新
clone 里没有这个文件，那种断言必然失败。代价是「改了接口忘了重新导出」没有自动
兜底，得手动跑 --check，已在 README 里点明。
398 测试全绿；另单独验证过缺 openapi.json 时该文件 5 个用例仍通过（CI 场景）。
compose 的变量插值行为只按文档核对，本机没有 docker 未能实测。
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
2026-08-14 14:27:38 +08:00 |
|