fix: order_result_unknown 补充"是否见过支付/待付款页"诊断标记 #302

Open
opened 2026-09-17 14:16:01 +08:00 by ila · 0 comments
Owner

来源:2026-09-17 排查 order_result_unknown 时讨论。用户原话:「要把已下单和后续的状态区分开,现在没有办法区分」。

现状

三个采购状态已存在:order_submit_started(点击下单前即记录,不可逆边界已过)→ order_created(订单号+下单时间都读到)/ order_result_unknown(没读全)。

问题在最后一步是全有或全无:parseOrderEvidence 要求订单号正则、下单时间正则、格式解析、待付款/支付文案同时命中才算 order_created,任何一项缺失就是 order_result_unknown,不区分"确实到过支付/待付款页只是没读全证据"和"根本没到那一步"。

线上实测:抓到的两次现场里,一次页面上订单编号、下单时间、待付款文案齐全(本该判成功却因返回窗口太短没采样到),另一次确实只是选择支付方式、订单尚未生成。两者当前都落进同一个 order_result_unknown,无法区分优先级。

方案

给 order_result_unknown 补一个诊断标记,不新增状态机分支。

Agent 端:readOrderResult 采样循环中,只要某一轮命中过 UNPAID_MARKERS(待付款/待支付/去支付)或 PAYMENT_MARKERS(立即支付/确认支付/输入支付密码),记一个布尔位 paymentPageObserved,与订单号是否解析成功无关。失败路径(unknown() 分支)连同这个标记一起上报。

服务端:PurchaseTask 新增 PaymentPageObservedAt *time.Time。SubmitResult 处理 order_result_unknown 时,若请求带 paymentPageObserved=true,写入服务端当前时间。

用途

order_result_unknown 按这个标记分两类:

  • 有 payment_page_observed_at —— 大概率已在 PDD 建了订单,只是没读全证据,优先核对
  • 没有 —— 很可能没走到那一步,风险低

为后续的 PDD 订单回填(按 address_suffix 匹配任务号)提供优先级依据,也是本单唯一的落地价值——先分层,回填单独建单。

非目标

  • 不改成功判定 parseOrderEvidence 的四项条件,不放宽 order_created 的判据。
  • 不新增采购状态,order_result_unknown 仍是唯一的终态值。
  • 不做 PDD 订单回填(依赖本单,另行建单)。
  • 不改支付页归位、返回重试次数等归位逻辑(另行建单,已有真机证据支撑)。
  • 不改批量重试是否新建任务的判断。

验收

  • 采样期间只要出现过待付款/支付相关文案,order_result_unknown 的记录必须带上该时间戳,无论后续是否解析出订单号。
  • 未出现过这类文案的 order_result_unknown 不带该字段。
  • order_created 与 failed 路径不受影响。
  • 幂等重放(同一 requestId 重复提交)行为不变。
  • 迁移只加列,不回填既有 107 笔历史记录(无法从历史数据反推是否见过支付页)。

验证

go test ./app/goauto/purchase/...;Android 单元测试覆盖 readOrderResult 采样标记逻辑。

文档影响

采购结果字段新增,需要更新 docs/08-agent-api-contract.md 的 order_result_unknown 请求体说明。

> 来源:2026-09-17 排查 order_result_unknown 时讨论。用户原话:「要把已下单和后续的状态区分开,现在没有办法区分」。 ## 现状 三个采购状态已存在:`order_submit_started`(点击下单前即记录,不可逆边界已过)→ `order_created`(订单号+下单时间都读到)/ `order_result_unknown`(没读全)。 问题在最后一步是全有或全无:`parseOrderEvidence` 要求订单号正则、下单时间正则、格式解析、待付款/支付文案**同时**命中才算 `order_created`,任何一项缺失就是 `order_result_unknown`,不区分"确实到过支付/待付款页只是没读全证据"和"根本没到那一步"。 线上实测:抓到的两次现场里,一次页面上订单编号、下单时间、待付款文案齐全(本该判成功却因返回窗口太短没采样到),另一次确实只是选择支付方式、订单尚未生成。两者当前都落进同一个 `order_result_unknown`,无法区分优先级。 ## 方案 给 `order_result_unknown` 补一个诊断标记,不新增状态机分支。 Agent 端:`readOrderResult` 采样循环中,只要某一轮命中过 `UNPAID_MARKERS`(待付款/待支付/去支付)或 `PAYMENT_MARKERS`(立即支付/确认支付/输入支付密码),记一个布尔位 `paymentPageObserved`,与订单号是否解析成功无关。失败路径(`unknown()` 分支)连同这个标记一起上报。 服务端:`PurchaseTask` 新增 `PaymentPageObservedAt *time.Time`。`SubmitResult` 处理 `order_result_unknown` 时,若请求带 `paymentPageObserved=true`,写入服务端当前时间。 ## 用途 `order_result_unknown` 按这个标记分两类: - **有 `payment_page_observed_at`** —— 大概率已在 PDD 建了订单,只是没读全证据,优先核对 - **没有** —— 很可能没走到那一步,风险低 为后续的 PDD 订单回填(按 `address_suffix` 匹配任务号)提供优先级依据,也是本单唯一的落地价值——先分层,回填单独建单。 ## 非目标 - 不改成功判定 `parseOrderEvidence` 的四项条件,不放宽 `order_created` 的判据。 - 不新增采购状态,`order_result_unknown` 仍是唯一的终态值。 - 不做 PDD 订单回填(依赖本单,另行建单)。 - 不改支付页归位、返回重试次数等归位逻辑(另行建单,已有真机证据支撑)。 - 不改批量重试是否新建任务的判断。 ## 验收 - [ ] 采样期间只要出现过待付款/支付相关文案,`order_result_unknown` 的记录必须带上该时间戳,无论后续是否解析出订单号。 - [ ] 未出现过这类文案的 `order_result_unknown` 不带该字段。 - [ ] `order_created` 与 `failed` 路径不受影响。 - [ ] 幂等重放(同一 `requestId` 重复提交)行为不变。 - [ ] 迁移只加列,不回填既有 107 笔历史记录(无法从历史数据反推是否见过支付页)。 ## 验证 `go test ./app/goauto/purchase/...`;Android 单元测试覆盖 `readOrderResult` 采样标记逻辑。 ## 文档影响 采购结果字段新增,需要更新 `docs/08-agent-api-contract.md` 的 order_result_unknown 请求体说明。
Sign in to join this conversation.
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: OPC/goauto#302