chengmaandClaude Opus 5
7ad82b7795
补齐 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>
21 lines
596 B
Go
21 lines
596 B
Go
package service
|
|
|
|
import (
|
|
"crypto/rand"
|
|
"encoding/hex"
|
|
)
|
|
|
|
// newID 生成一个随机编号，用作 result_id 之类的标识。
|
|
//
|
|
// 没用 UUID 库是为了少一个依赖——这里只要求"够随机、不重复"，
|
|
// 16 字节的随机十六进制串完全够用。
|
|
func newID() string {
|
|
buf := make([]byte, 16)
|
|
if _, err := rand.Read(buf); err != nil {
|
|
// crypto/rand 读失败说明系统熵源出了问题，这种情况极罕见。
|
|
// 返回空串让调用方的响应里 result_id 为空，总比 panic 掉整个进程好。
|
|
return ""
|
|
}
|
|
return hex.EncodeToString(buf)
|
|
}
|