 chengma
|
c59b4b0d59
|
fix: 修复 PDD 页面误判与失败回执 (#35)
|
2026-08-07 17:58:30 +08:00 |
|
|
chengma
|
93beef8b36
|
feat: 保存并展示 PDD 店铺与价格采样信息 (#31)
|
2026-08-07 17:13:25 +08:00 |
|
|
chengmaandClaude Opus 5
|
998c06a2bf
|
feat: PDD 商品数据独立成表 (#16)
原来 pdd_data 是 shopee_products 上的一个 JSON 字段，两个蝦皮商品指向
同一个 PDD 链接时会各存一份、各采一次；collect_status 描述的是 PDD 商品的
状态，却挂在蝦皮商品上，两份可能不一致。
更要紧的是 PDD 商品变动频繁（A 下架就得换 B），而 sku_mappings 只按
shopee_sku_id 做键——换商品后旧映射还在，B 恰好有同名规格但完全是另一件货
时会静默买错，事后查不出来。
改动
- 新增 pdd_products 表：id 主键 + goods_id UNIQUE + 4 个状态值（去掉
no_link，「未填链接」改由 shopee_products.pdd_goods_id 为空表达）+
软删除可复活
- shopee_products 去掉 pdd_data / collect_status / collect_error /
collected_at，pdd_goods_id 改为引用
- sku_mappings 主键改为 (shopee_sku_id, pdd_goods_id)，新增 pdd_option_key。
查映射永远带上当前 PDD 商品，换商品后天然查不到旧映射，不需要删数据；
换回原商品时旧映射直接复用
- 新增 OptionKey()：用 json.Marshal 实现（Go 序列化 map 按键名排序，
天然规范化），不自己拼字符串——规格文字里可能含 = 或 ;。
存映射和查 SKU 必须用同一个函数，各写一遍会静默算出不同结果
- 采集结果改落 pdd_products，新增两条校验：
返回的 goods_id 与请求不符 → 整体回滚拒绝（422），不静默存下；
skus 为空数组 → 置 failed 而非 collected，否则界面显示"已采集"
但数据毫无用处
实施时超出工单但必要的三处
- TaskExists 重构为 GetTaskInfo：原函数只返回蝦皮 goods_id，
而采集结果要按 PDD goods_id 落库，不改取不到正确的键
- 复活时一并清空旧采集结果（skus_json / collect_msg / collected_at），
否则复活后会显示"已采集"但数据是删除前的
- 删除 repository/shopee.go：两个函数签名全变且已迁到 pdd.go，留着是死代码
已验证（Go 1.23.0）
- go vet / gofmt / go test 全过，55 个测试
- 端到端补验了工单未覆盖的 HTTP 层：goods_id 不符返回 422
COLLECT_GOODS_MISMATCH 且整体回滚（skus_json 空、任务仍 claimed、
幂等记录 0 条）；skus 为空返回 200 但状态 failed
遗留
- MarkCollecting / SoftDeletePddProduct 暂无调用方，等界面工单接上
- artifact_ref 存 diagnostics 原始 JSON，未按 client-001:artifacts/... 规范化，
因 Client 侧尚未定义 diagnostics 结构
- 界面未实现（工单明确排除），四个页面仍为骨架
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-07 10:27:39 +08:00 |
|
|
chengmaandClaude Opus 5
|
5a5c1f1f68
|
feat: 新增幂等 Client 登记接口 (#12)
PUT /api/v1/client/registration —— 设置页点"保存"时调用，
只登记客户端，不碰任务。
为什么需要它
原设计"注册就在 claim 里做"有个真问题：设置页保存被迫调 claim，
而 claim 可能真的领到一个任务——Admin 那边已把任务标成 claimed，
Client 必须可靠落库否则任务就丢了。一个"保存设置"的动作
不该承担"领取任务并保证不丢"的责任。这违反了本项目自己的原则
（05 §1：界面上只有一个会产生外部后果的命令）。
实现
- ClientProfileRequest + Validate() 由**登记和领取共用**，
避免两个入口的结构和校验各写一份、迟早漂移
- 校验：名称 <=50 字（按字符不按字节，中文一个字三字节）、
supported_types 非空且只含 collect/purchase、platform 只支持 android、
purchase_mode 必填且只允许 dry_run/live、schema_versions 均为正整数
- 非法内容返回 422 INVALID_CLIENT_PROFILE，错误消息指明具体字段
- UpsertClient 加 explicit 参数区分名称规则：
显式登记（用户点保存）带非空名称时更新名称；
隐式登记（claim 顺带）永不更新，否则操作员改的名字会被反复冲掉
已验证（Go 1.23.0）
- 单元测试 40 个全过，含"登记不产生任何任务副作用"的快照比对
- 端到端逐条走完手册 §5.2~5.7：重复登记记录数恒为 1；
更新/空名称行为正确；插入任务后登记 3 次任务字段完全未变且仍可领取；
四种非法输入均 422 且不写库；claim 不受影响
一处行为变更需注意
名称归属规则改了：原来是"Admin 操作员永远赢"，现在是"最后一次
显式操作赢"——用户在 Client 点保存会覆盖 Admin 侧改的名字。
按 #12 文档实现，已拆成三个独立测试盯住三种情况。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-06 17:31:38 +08:00 |
|
|
chengmaandClaude Opus 5
|
7ad82b7795
|
feat: 实现结果提交接口与幂等处理
补齐 submit_result / submit_failure，Admin 侧的三个接口全部可用，
Client 的完整一圈（领取 → 执行 → 提交）现在能走通了。
实现
- 幂等：idempotency_keys 表。同键同内容返回上次的响应且不重复落库，
同键不同内容返回 409。幂等记录与业务写入在**同一事务**，
分开写的话业务成功但幂等没记上，重试会被重复处理
- 无条件接受（契约 §4.1，最容易写错的一条）：
任务已取消、已重派给别人，都照样接受结果——客户端中途不查任务状态，
必然会提交"Admin 这边已经不要了"的结果，而它可能真的已经下过单，
这些数据必须留痕
- 采集任务的结果落到商品级 shopee_products.pdd_data 并置 collected；
失败则置 failed 并把原因写进 collect_error，操作员才看得见
- 失败状态映射：retry_wait→assigned，其余同名
- 三个接口都刷新 last_seen_at
新增 task_claims 表（migrations v2）
契约要求"只有从未分配给该客户端的任务才返回 403"，但 assigned_client
只记当前归属，重派后就查不出原来那台领过——而契约又要求那种情况必须接受。
没有这张表这条规则根本没法判断。顺带得到一份审计记录。
修复第二个并发 bug：事务必须 BEGIN IMMEDIATE
并发提交报 SQLITE_BUSY。根因是 Go 的 db.Begin() 默认发 BEGIN DEFERRED，
事务开始时不拿写锁，多个事务各自先读再想升级成写就互相卡死，
这种情况 busy_timeout 救不了。DSN 加 _txlock=immediate 后事务一开始
就排队拿锁。实测 6 个并发事务：默认失败 5/6，加参数后 0/6。
已写进 docs/admin/03-data-model.md §2.1。
已验证（Go 1.23.0）
- 30 个单元测试全过，并发用例重复 20 次稳定通过
- 端到端：claim 200 → 提交 200 → 重复提交返回完全相同的响应 →
同键不同内容 409 → 没领过的客户端 403 → 任务不存在 404 →
缺 Idempotency-Key 400；库里 task=succeeded、幂等 1 条、领取历史 1 条
说明：Gitea 尚未配置，本次无对应工单号。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-06 17:04:49 +08:00 |
|