chengma
|
e1b32ea024
|
feat: 固定创建真实采购任务 (#112)
|
2026-08-10 17:52:48 +08:00 |
|
chengma
|
13cfced80d
|
feat: 迁移 Admin Repository 到 MySQL 8 (#79)
|
2026-08-10 02:21:31 +08:00 |
|
chengma
|
155dd3b4a2
|
feat: 统一 Admin 主列表分页 (#64)
|
2026-08-09 21:51:20 +08:00 |
|
chengma
|
e0c0dac7a0
|
feat: 增加客户端采购员归属管理 (#54)
|
2026-08-09 16:02:25 +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
|
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 |
|