jp/rakuten-api
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
43 Commits 1 Branch 0 Tags
4cc30bc058547d4e5ca91d03d8fbe8883ebd9bb7
Commit Graph
14 Commits
Author SHA1 Message Date
q792602257andClaude Opus 5 4cc30bc058 feat(observability): /health 不再产生 server span 
容器 HEALTHCHECK 每 30 秒探一次、上游也在轮询，这些请求各自是一条孤立
trace，量大且没有信息量——和 worker 空转长轮询同一个问题，把观测后台刷满
的正是它们。

instrument_app 传 excluded_urls，由新增的 RAKUTEN_OTEL_EXCLUDED_URLS 控制
（默认 /health$）。按 search 匹配完整 URL，锚点保证不误伤 /api/health-*；
留空时传 None，回落到 OTel 自己的 OTEL_PYTHON_FASTAPI_EXCLUDED_URLS。

三个服务共用 instrument_app，因此抓取/交易/网关一并生效。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-28 15:24:52 +08:00
q792602257andClaude Opus 5 3c7618a1d6 feat(observability): 抓取去掉首页预热，交易补齐链路埋点 
两个问题一起处理，都与「出站请求与可观测性」有关。

## 抓取：正常路径不再多打一次首页

site_session 原先每条通道每 30 分钟打一次 www.rakuten.co.jp/ 做预热，而且预热
返回非 2xx 时 warmed_at 不置位——那种情况下每个请求前都会再打一次首页。

Akamai 的 cookie 随任意页面响应下发，目标页自己就会带回来，专门先打一次首页除了
多一个出站请求（以及多一次被风控计数的机会）之外没有额外收益：首个请求无论打哪个
URL 都是冷的 ~11s，之后都复用 cookie。

改为 cookie 由目标页响应建立（_note_cookies）、超 TTL 主动清空
（_drop_expired_cookies）。首页只保留在失败修复路径上（_rewarm_on_home）：目标页
已经吃了挑战页时，拿首页换一套干净 cookie 比继续撞同一个 URL 更安全。happy path
的出站请求数 2 → 1。

_note_cookies 刻意不在每次响应时刷新时刻：TTL 要从「这套 cookie 第一次出现」算起，
每次都刷新会让一套 cookie 被无限续命，反而绕过了 session_ttl_seconds 的本意。

profile_status() 的 warmed 字段名保留（上游健康检查看板在用），语义改为「当前有
可复用的 Akamai cookie」，不再代表「已专门预热过首页」。

## 交易：此前没有任何有意义的链路数据

根因是 trading 的实际工作两类自动埋点都覆盖不到：站点交互走 Playwright（不经
httpx），worker 主循环是后台 asyncio 任务（没有 HTTP 入口，因此没有根 span）。
于是发给网关的每次 httpx 调用各自成为孤立 trace——观测后台上只剩一堆请求记录。

新增手工埋点：

- order.task：一笔下单的根 span，一个 task_id 一条 trace，带 order.route
  （execute / recovery / already_finished）与终态 order.terminal_status
- order.step.*：清车 → 加购 → 校验 → 确认 → 提交 → 付款，每步一个子 span，
  带 order.evidence_ref，可从 span 直接定位落盘证据
- site.*：12 个 Playwright 交互方法（用 traced 装饰器而非 with 块——这些方法的
  函数体本就很长，再加一层缩进不利于阅读）
- account_query：只读查询单的根 span，带 query.outcome

空转的长轮询（30 秒一次、绝大多数返回空）用 suppressed() 屏蔽：量大且没有信息量，
把观测后台刷满的正是它们。领到任务后的网关调用都在任务根 span 底下，不受影响。

闸门 / 风控拦截会被 _execute_with_renewal 吞掉转 needs_human，异常冒不到根 span，
被拦下的单在 trace 里跟成功下单一模一样。加 _execute_recording_errors 一层统一
记录，比每个 except 分支各写一遍省事，也不会漏掉后续新增的分支。

_report_safe 写 span 属性前判断 is_recording()：付款后监控是 create_task 起的，
asyncio 在创建时就把 context 复制了进去，等它真正跑起来根 span 早已结束——
get_current_span() 拿到的仍是那个已结束的 span（不是 INVALID_SPAN），写属性会打
"Setting attribute on ended span"。当前监控路径不传 terminal_status 走不到那里，
这道判断是防以后。

## 顺带修掉：instrument_app 从未生效

instrument_app 用 _provider is None 做前置判断，但三个服务都在模块导入时执行
app = create_app()，而 setup_telemetry 要等 lifespan 才跑——那时 _provider 还是
None，照着判断直接 return。**FastAPI 从来没被打桩过，三个服务一条 server span
都没有。**

实测确认两件事：导入期打桩能出 span，lifespan 内打桩出不来（instrument_app 是加
中间件，应用开始服务后加进去不生效）；provider 后设也不影响 ProxyTracer 委托到
真实 provider。所以只能在导入期装，判断条件改为 otel_enabled。

app/gateway/main.py 此前完全没接 telemetry，worker 出站请求带过来的 traceparent
没人接上，一条下单链路在网关这里断掉，只看得到 worker 侧那半截。补上
setup_telemetry(service_name="rakuten-gateway") 与 instrument_app / shutdown。

## 验证

新增 8 个用例：首页零请求、cookie 复用与过期清空、失败后用首页换 cookie、一任务
一 trace 的父子结构、闸门失败标 ERROR、空转不埋点，以及 instrument_app 调用顺序
的回归测试。全量 526 passed。

Playwright 那些 site.* 埋点只做了静态验证（测试用桩替换站点方法），没有跑真实
浏览器下单确认 span 真的落地。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-28 14:56:49 +08:00
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 daa5555fd4 fix(trading): cart count status=101 识别为空车，区分空车与获取失败 2026-08-17 01:42:08 +08:00
q792602257andClaude Opus 5 c03158488b feat(gateway): 账号只读查询通道——从已登录账号取真实订单 
上游要的不只是网关记的任务状态镜像，还有「已登录账号在站点上的真实订单」，
但账号只在 NAT 后本地机上，只能经网关队列走。新增独立查询通道（§11）：

- gateway 单开 account_queries 表 + QueryStatus 状态机，接口
  POST /api/account/queries（幂等）/ lease / {id}/result / {id}
- 不复用下单任务队列：查询是只读，租约过期可安全重投（与下单「绝不自动
  重投」相反），且不该被全局并发度 1 堵死、task_reports 是订单镜像不能污染
- 本地交易服务起第二条常驻循环 query_runner，领到即调 SiteInteractor 真读：
  order_list 复用已实测的 list_recent_orders（规范化字段 + 站点
  orderListData 原文），order_detail 复用 fetch_order_detail（配送阶段 +
  页面 __INITIAL_STATE__ 原样透传，结构未经真实样本，不抽字段）
- 账号级串行仍由 SiteInteractor 的锁保证；每次执行套超时按失败回报
- 错误码 6005/6006（查询通道，可重试只读区别于 6001-6004）；/health 暴露
  queued_query_count；结果体积上限先丢原始 JSON

openapi.json 重导，docs/order-gateway.md §11、README、.env.example 补全
配置与实测边界。全量测试 404→454 通过。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-08-16 22:46:01 +08:00
q792602257 6c38089234 feat(docker): add scraping API compose service 2026-08-16 21:04:28 +08:00
q792602257 fabca9510d feat: 为出站请求统一接入 HTTP 代理 2026-08-14 16:08:39 +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
q792602257andClaude Opus 4.6 55c01ae4f5 加 /api/cart/* 接口；加购链路完全归 trading 
trading 新增 4 条购物车接口（POST /api/cart/{add,status,clear,remove}），
全部 Bearer 鉴权、走 SiteInteractor（Playwright + storage_state）。同步把
SiteInteractor 从 gateway URL 解耦——lifespan 总是构造与启停，container
字段 worker_site → site，加 asyncio.Lock 让 HTTP 与 worker 共用同一把锁
（同账号串行硬约束）。clear/remove 用 UI 点击 button[aria-label="削除"]，
探针回报这是稳定 selector；真账号实测前先用此路径。

抽 ichiba 加购字段解析到 app/shared/purchase_contract.py（常量 +
inventory_flag_for + basket_domain_of + base_form_fields），原本 scraping
与 trading 重复实现同一段 __INITIAL_STATE__.purchase 解析。进一步发现
README 写的「purchase 块是两服务契约」实际未落地——trading 必须 Playwright
开页（httpx 被 TLS 指纹拦死），本地抽比再调 /api/item_detail 更快更新鲜。
删除 scraping 端 PurchaseInfo/PurchaseOption/PurchaseOptionValue 模型、
各站 _purchase_info 函数、tests/test_purchase.py。ItemDetailData 保留
purchase_condition / is_sold_out / purchase_unit / sku 等商品状态字段。
README「加购与下单」段重写。

328 测试全绿（含架构测试守住三方互不 import）。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-07-28 17:18:00 +08:00
q792602257andClaude Opus 4.6 65e3ed31f8 交易服务收敛为仅 rakuten：移除 rakuma 登录态与下单入口 
trading 不再管理 ラクマ 的购物车购买、支付与订单监控。删除 auth_site /
auth_session / login_runner / models.AuthSite 中的 rakuma 分支与常量、
account.yaml.example 的 rakuma 段，并清理相关测试。scraping 侧的
ラクマ 抓取 API（/api/rakuma/*）保留不动。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-07-28 11:50:07 +08:00
q792602257andClaude Opus 4.6 07107094a7 实现下单任务网关与本地 worker 
按 docs/order-gateway.md 落地：第三个部署单元 app.gateway（:31109）承担任务队列
+ 状态镜像；本地 worker 在 app.trading.worker 内，按 RAKUTEN_ORDER_GATEWAY_URL
决定是否启动。规格 §5 最关键约束已守：租约过期绝不自动重投，恢复只能 reclaim，
worker 收到 lease_count>1 时先核对站点订单。

站点交互（加购/下单/付款/订单列表反查）按规格 §10 留接口缝，site_interact.py
全部 NotImplementedError，verify.py 恒返回 unknown——等真实账号实测后再填，
不写猜测的提交逻辑。

310 个测试全绿，覆盖规格 §9 验收清单 12 条；架构测试守住三方互不 import。

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
 2026-07-27 16:25:20 +08:00
q792602257 5376ced511 补下单任务网关规格 
抓取在服务器、下单在本地，本地在 NAT 后没有公网入口，因此下单请求由本地长轮询
主动领取，而不是从服务器推进来。docs/order-gateway.md 给出可直接实现的规格：
任务队列与状态镜像的表结构、四个接口契约、任务状态与订单状态的分层、证据留痕约定、
配置项与验收清单。

其中一条是安全关键：租约过期**不自动重投**。本地可能已经下单成功只是回报断网，
自动重投等于再买一次；过期任务转 stale 告警，恢复时必须先查站点订单列表核对。

站点交互（加购/下单/付款）尚未实测，文档里明确留成接口缝并列出待实测项。
 2026-07-27 15:20:11 +08:00
q792602257andClaude Opus 5 104d7fef6b 拆分抓取与交易服务 
把需要账号登录态的链路从抓取服务里拆出成独立进程。分界线不是「要不要登录」，
而是抓取无状态、幂等、可多开实例，而交易的写操作不可逆、登录态全局唯一、
订单监控是常驻轮询——同进程时抓取一扩容就会复制出 N 份登录态与 N 个轮询，
同一账号会被并发操作。

- app/shared：配置、错误码、日志、ApiResponse 信封 + Bearer 鉴权 + 异常处理器、
  导航请求头构造器
- app/scraping：站点常量、会话、解析器与 10 个抓取接口，:31107，可多开
- app/trading：登录态查询/重载与健康检查，:31108，只能单实例
- 依赖方向锁为 scraping→shared、trading→shared，两侧互不 import；
  tests/test_architecture.py 用 AST 检查 import 并校验两个 app 的路径不串
- 登录态 UA 在 trading 独立持有：与抓取 UA 值相同但变更理由不同，抓取 UA 为绕
  反爬可随时调整，登录 UA 一改可能触发设备校验使已落盘 cookie 失效
- scripts/login.py 与 AuthSession 共用 auth_site.PROFILES 与 is_logged_in，判据只写一遍
- 同一镜像两个启动命令，交易容器覆盖 command 并设 RAKUTEN_HEALTH_PORT

同时带上此前未提交的 ラクマ 分类接口与登录态基础设施。

验证：239 个离线用例全绿；两个入口真实启动，/health 与鉴权正常。
未验证：真实探测登录态（当前开发机无外网，对站点的连接全部超时）。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
 2026-07-27 15:05:01 +08:00
q792602257 3527975794 Init 2026-07-27 10:34:53 +08:00