chengma/cmautobuy
2
0
Fork 0
Code Issues 89 Pull Requests Actions Packages Projects Releases Wiki Activity
344 Commits 1 Branch 0 Tags
cd1fc8ae680a0d21047a0f8c2f236e8e43be6c8b
Commit Graph
12 Commits
Author SHA1 Message Date
chengma a9f22b9b0e feat: 按创建人隔离采集采购任务 (#127) 2026-08-10 23:10:28 +08:00
chengma 3aaa40cfe0 feat: 增加真实采购任务安全模式 (#98) 2026-08-10 15:11:38 +08:00
chengma 13cfced80d feat: 迁移 Admin Repository 到 MySQL 8 (#79) 2026-08-10 02:21:31 +08:00
chengma d99c81310d feat: PDD 批量采集支持可选客户端 (#74) 2026-08-10 00:49:51 +08:00
chengma 4433e3af37 feat: 完成规格映射与采购任务创建 (#69) 2026-08-09 22:55:14 +08:00
chengma 155dd3b4a2 feat: 统一 Admin 主列表分页 (#64) 2026-08-09 21:51:20 +08:00
chengmaandClaude Opus 5 f0d7da37cf feat: 采集采购页，采集与采购统一展示 (#19) 
原来的采购任务页是骨架：var rows []gin.H 从不查库，页面永远为空；
TODO 写的还是只查 task_type = 'purchase'。所以 #18 建出来的采集任务
在界面上哪儿都看不到——用户点完「创建采集任务」只能盯着
collect_status 猜。

模块名定为「采集采购」（用户指定），直接点出这页装的是哪两类任务，
比泛称「任务」更能让人一眼知道点进去看什么。路由 /tasks 不变，
改路由会让已有书签和文档链接全失效，没有收益。

列不按类型并列——两种任务字段完全不同，并列会让采集任务行一半是空列。
改成固定列 + 一列「目标」把业务信息概括成一句话：
  采集  PDD 737116531267
  采购  SO-001 · M/黑色 · 2件 · ≤¥42.00
拼接逻辑在 service 层，模板只负责显示。

统计和列表共用同一个筛选条件拼装函数。分开写的话总有一天会忘了
给统计也加条件，数字和表格对不上，操作员会以为页面坏了。

无主任务的客户端列显示「—」。#17 之后采集任务默认无主，这列会大量为空。

详情弹窗只读，采购专有字段（数量、价格上限、目标规格）在采集任务里
整段不出现，不显示空行。复用 #18 的弹窗机制，app.js 无需改动。

顺带清掉 PDD 页加进来之后一直没跟上的模块计数：多处「四个模块/四个页面」
改成五个。其中 06-quality-security.md 那两处是验证清单，
照着做的人只会测四个页面，PDD 页永远不在回归范围里。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 15:16:05 +08:00
chengmaandClaude Opus 5 eb8d357f5a feat: PDD 商品页面 (#18) 
打通 Client↔Admin 闭环的一环：录入 PDD 链接 → 创建采集任务 →
客户端领走去采 → 规格和价格显示在页面上。#16 写的 MarkCollecting 和
SoftDeletePddProduct 至此才有生产调用方。

链接解析严格、不做容错兜底：goods_id 上有 UNIQUE 约束，防重全靠它。
猜一个的话同一商品会存成好几行、采好几遍，规格映射还说不清指向哪一行。
短链一律拒绝，卡域名是为了拦"粘了淘宝链接"这种失误。

创建采集任务先占状态再建任务：MarkCollecting 只在 pending/failed 时成功，
同时充当"有没有人已经在采"的判断，与建任务在同一事务里，
所以并发点多次只会建出一个任务（实测 4 并发 → 1 条）。

submit.go 的 collectedData 增加 Dimensions —— 没有它就只能按 Go 的 map
遍历，而 map 无序，同一商品每次刷新"颜色/尺码"的先后都可能变。

顺带修 #16 一处缺陷：EnsurePddProduct 复活分支清空了 skus_json 却漏了
title，导致复活后状态显示"未采集"但标题还留着旧值。

审查打回一次：清理"PDD 链接唯一的录入口"这一过期说法（全库 5 处），
以及 shopee.go 里"空 → no_link"的过期 TODO —— no_link 已在 #16
从 CHECK 约束删除，照写会直接撞约束。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 11:27:06 +08:00
chengmaandClaude Opus 5 dd387e3ee5 feat: claim 支持领取无主任务 (#17) 
PDD 商品页要能「创建采集任务」而不指定客户端——采集只是浏览商品页，
没有副作用，哪台设备采都一样。但原来的查询是

    WHERE assigned_client = ? AND status = 'assigned'

无主任务（assigned_client 为空 + pending）永远没人能领，建出来就是死的。

改动
- ClaimNextTask 同时查两种：指定给本机的 + 无主的
- 排序 ORDER BY (assigned_client IS NULL), priority DESC, created_at
  ——指定给本机的优先。显式分配是人为决定，应当先兑现
- 原子更新两种情况合成一条语句：对"指定给我的"写 assigned_client
  是写同一个值无副作用；对无主的，这一步就是"谁领到就标记谁"
- 表结构不用动（assigned_client 本来可空，status 已有 pending）

推翻了一条已定案的规则
Client 契约 §5.1 原写「Admin 只把任务分配给指定的 Client」，
现改为两种并存并说明各自适用场景：
- 采集任务不指定客户端
- 采购任务可指定可留空。涉及钱和账号——不同设备可能登着不同的
  拼多多账号，需要指定账号时必须显式分配，留空即接受"谁先抢到谁下单"

Client 侧对两种没有区别，不需要知道任务原来有没有主。

已验证（Go 1.23.0）
- 新增 7 个测试，全量 62 个全过
- 并发抢占用例重复 20 次稳定：8 个客户端抢同一条无主任务，
  正好 1 个拿到，且 assigned_client 记的就是那个赢家
- 既有测试未受影响，"只领分配给自己的"仍然成立

一处仍未解决的风险（已记入 #17 风险表）
tasks 表没有字段标记"该任务需要真实下单"，所以契约里
"不向 dry_run 客户端分配真实下单任务"实际无法执行。
真实下单开关关闭时不出问题，开启前必须补该字段。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 10:53:32 +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 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
chengmaandClaude Opus 5 6ae768463f feat: 实现客户端注册与任务领取接口 
Admin 的第一个业务功能。选它打头是因为它是穿透所有层的最薄一条竖切
（HTTP → handler/api → service → repository → SQLite → handler/web → 页面），
一个工单把分层模式立起来，后面四个模块照抄；同时它是与 Client 联调的接口，
能解锁另一条并行的工作线。

实现
- POST /tasks/claim：注册 + 领取。注册就在这里做，没有单独的注册接口，
  也没有心跳（理由见 docs/admin/04-client-api.md §3）
- 领取用条件更新 + 检查影响行数防并发，SQLite 没有 SELECT FOR UPDATE
- 客户端列表页：查询、按名称搜索、批量删除
- 在线状态是**算出来的**（last_seen_at 在 10 分钟内），数据库里没有该字段
- CSRF 中间件：双提交 Cookie，手写 82 行不引依赖。
  **只挂页面路由**，/api/v1/client/* 不能加——Client 不是浏览器、没有 Cookie
- 14 个单元测试

修复一个真 bug：PRAGMA 必须写进 DSN
并发领取测试报 database is locked (SQLITE_BUSY)。根因是
PRAGMA busy_timeout 每连接生效，而 database/sql 是连接池——
db.Exec("PRAGMA ...") 只作用于当时那条连接，池子新开的连接没执行过。
单线程正常、一并发就炸。改成 DSN 传参后并发测试跑 20 次全过。
这个坑已写进 docs/admin/03-data-model.md §2.1。

与工单的两处差异
- 去掉 name_is_custom 列后，"人工改的名字不被覆盖"改用更简单的做法：
  ON CONFLICT DO UPDATE SET 里不含 name，即只在首次注册时写入。
  效果相同，零额外字段、零迁移。已同步 04 §3
- 验收项"不向 dry_run 客户端分配真实下单任务"**未实现**：
  tasks 表没有字段标记任务是否需要真实下单。当前真实下单开关默认关闭、
  MVP 全是演练模式，暂不出问题，但开真实下单前必须补该字段，需另开工单

已验证（Go 1.23.0）
- go vet / gofmt / go test 全过，并发测试重复 20 次稳定通过
- 端到端：无任务 claim 204；插入任务后 claim 200 且 payload 含
  goods_url/goods_id/options/quantity/max_price_cent、无租约无 Admin 状态；
  重复 claim 204；缺 X-Client-Id 400；POST 无 CSRF token 403；
  列表页两台客户端在线状态与统计正确

说明：Gitea 尚未配置，本次无对应工单号。
submit_result / submit_failure 及其幂等处理留给下一个工单。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-06 16:56:18 +08:00