Admin：任务主键改为采集 cj 与采购 cg 独立自增编号 #172

New Issue

2026-08-12T08:57:51+08:00

ila commented

2026-08-12 08:57:51 +08:00

基本信息

类型：需求
父级大工单：#14
所属 MVP / 版本：#15 Admin 四模块可用闭环
阶段：采集采购任务标识与生产迁移
当前状态：待验收

要解决什么

客户要求把真实 tasks.task_id 主键改为两套独立、从 1 开始递增的业务单号：采集任务为 cj1、cj2…，采购任务为 cg1、cg2…。原随机 COL-/PUR- 编号不便于采购员口头沟通和按单号查找。

生产迁移前只读核对：共 5 条任务，采集 3 条（1 assigned、2 succeeded），采购 2 条（均 succeeded）；没有活动或待人工核对采购。2 条成功采购均已有 PDD 订单编号和下单时间。存在 5 条有效领取历史、1 条顺运宝来源关联和 17 条孤儿领取历史。

做什么 / 不做什么

做：

直接修改真实 task_id 生成规范，不保留额外展示编号。
采集和采购分别使用独立事务序列，从 cj1、cg1 开始递增。
MySQL v13 将存量任务按 task_type + created_at + 旧 task_id 稳定排序，分别重编号并同步所有有效关联。
清理无法关联现存任务的孤儿 task_claims。
页面、搜索、日志和 Client 四接口统一使用新任务 ID；接口继续把 ID 当不透明字符串。
更新 Admin/Client 契约文档和自动化测试。

不做：

不保留旧随机 ID 别名或第二套展示编号。
不修改 Client 本地数据库；用户已确认 Client 可在迁移完成后停止并清除本地任务数据。
不改变任务状态、采购结果、执行模式、领取和结果/失败提交语义。
不新增自动付款、重试下单或绕过采购安全门禁的行为。

怎么做

新增 task_sequences(task_type,current_value)，固定两行 collect/0、purchase/0；分配时在创建任务的同一事务内先原子递增再读取，禁止 MAX()+1。
Repository 提供按任务类型分配 cjN/cgN 的唯一入口，采集和采购 Service 不再调用随机 ID。
MySQL v13 使用可重放的映射/迁移步骤：建立序列表；稳定生成旧 ID → 新 ID 映射；同步 tasks、task_claims、task_syb_sources；删除孤儿领取历史；校准两套 current_value；完成结构、格式、引用完整性和序列自检后才记录 v13。
新库和 v12 升级得到相同结构；重复启动不得二次重编号。
列表继续显示任务 ID 和明确类型文字，关键词支持编号搜索；Client payload 直接传输 cjN/cgN。
同步更新 Admin/Client 数据模型、接口契约和界面规范。

预计修改：

admin/repository/mysql_db.go
admin/repository/task.go
admin/service/pdd.go
admin/service/purchase_workflow.go
对应 migration/repository/service 测试
Admin/Client 契约、数据模型和界面文档

验收标准

空库第一条采集任务为 cj1，第一条采购任务为 cg1，两套序号互不影响。
并发创建不会产生重复 ID，不使用 MAX()+1。
删除任务后序号不回收、不复用。
v12 存量任务按稳定顺序迁为独立 cjN/cgN，任务字段、状态、结果和创建人不变。
有效 task_claims、task_syb_sources 全部指向新 ID，孤儿领取历史被清理。
v13 中断可重放；首次建库、v12 升级和重复迁移自检通过。
列表、详情、搜索、领取、结果提交、失败提交都接受并使用新编号。
Client 四接口数量、路径和业务语义不变，Client 仍把任务 ID 当不透明字符串。
成功采购仍保留 PDD 订单编号和下单时间，#169 重复采购门禁不受影响。
固定 Go 1.23.0 全量测试、vet、构建通过，真实 MySQL 8.4 _test 库迁移和并发测试通过。
生产备份后迁移到 v13：存量为 cj1…cj3、cg1…cg2，下一号分别为 cj4、cg3，服务健康。（迁移与健康核对已完成；但 v13 在计划停服备份前被另一个连接生产库的当前源码进程提前触发，只生成了迁移后备份，交由用户验收此偏差。）

怎么验证

Set-Location admin
$env:GOTOOLCHAIN='go1.23.0'
go test ./... -count=1
go vet ./...
go build ./...

另在独立 MySQL 8.4、库名以 _test 结尾的测试库验证首次建库、v12 升级、重复迁移、并发分配和关联完整性。生产部署后只读核对任务编号、任务结果、关联计数、schema、systemd 和公网健康状态。

风险和回退

风险：Client 持有旧 ID 时会向旧路径提交。控制：生产没有活动采购；用户确认迁移后可清除 Client 本地任务再启动。
风险：主键重编号遗漏关联。控制：迁移前后逐表计数、引用完整性和成功采购结果结构自检。
风险：顺序号可枚举。说明：按客户确认规范实施；Client API 认证强化另行立项，不用随机 ID 代替认证。
回退：v13 会改写主键，代码回退必须同时恢复数据库备份，不允许只回退二进制。生产 v13 被提前触��后已生成并校验迁移后备份，且保留既有历史备份；具体偏差见完成记录。

## 基本信息 - 类型：需求 - 父级大工单：#14 - 所属 MVP / 版本：#15 Admin 四模块可用闭环 - 阶段：采集采购任务标识与生产迁移 - 当前状态：待验收 ## 要解决什么客户要求把真实 `tasks.task_id` 主键改为两套独立、从 1 开始递增的业务单号：采集任务为 `cj1、cj2…`，采购任务为 `cg1、cg2…`。原随机 `COL-/PUR-` 编号不便于采购员口头沟通和按单号查找。生产迁移前只读核对：共 5 条任务，采集 3 条（1 assigned、2 succeeded），采购 2 条（均 succeeded）；没有活动或待人工核对采购。2 条成功采购均已有 PDD 订单编号和下单时间。存在 5 条有效领取历史、1 条顺运宝来源关联和 17 条孤儿领取历史。 ## 做什么 / 不做什么做： - 直接修改真实 `task_id` 生成规范，不保留额外展示编号。 - 采集和采购分别使用独立事务序列，从 `cj1`、`cg1` 开始递增。 - MySQL v13 将存量任务按 `task_type + created_at + 旧 task_id` 稳定排序，分别重编号并同步所有有效关联。 - 清理无法关联现存任务的孤儿 `task_claims`。 - 页面、搜索、日志和 Client 四接口统一使用新任务 ID；接口继续把 ID 当不透明字符串。 - 更新 Admin/Client 契约文档和自动化测试。不做： - 不保留旧随机 ID 别名或第二套展示编号。 - 不修改 Client 本地数据库；用户已确认 Client 可在迁移完成后停止并清除本地任务数据。 - 不改变任务状态、采购结果、执行模式、领取和结果/失败提交语义。 - 不新增自动付款、重试下单或绕过采购安全门禁的行为。 ## 怎么做 1. 新增 `task_sequences(task_type,current_value)`，固定两行 `collect/0`、`purchase/0`；分配时在创建任务的同一事务内先原子递增再读取，禁止 `MAX()+1`。 2. Repository 提供按任务类型分配 `cjN/cgN` 的唯一入口，采集和采购 Service 不再调用随机 ID。 3. MySQL v13 使用可重放的映射/迁移步骤：建立序列表；稳定生成旧 ID → 新 ID 映射；同步 `tasks`、`task_claims`、`task_syb_sources`；删除孤儿领取历史；校准两套 `current_value`；完成结构、格式、引用完整性和序列自检后才记录 v13。 4. 新库和 v12 升级得到相同结构；重复启动不得二次重编号。 5. 列表继续显示任务 ID 和明确类型文字，关键词支持编号搜索；Client payload 直接传输 `cjN/cgN`。 6. 同步更新 Admin/Client 数据模型、接口契约和界面规范。预计修改： - `admin/repository/mysql_db.go` - `admin/repository/task.go` - `admin/service/pdd.go` - `admin/service/purchase_workflow.go` - 对应 migration/repository/service 测试 - Admin/Client 契约、数据模型和界面文档 ## 验收标准 - [x] 空库第一条采集任务为 `cj1`，第一条采购任务为 `cg1`，两套序号互不影响。 - [x] 并发创建不会产生重复 ID，不使用 `MAX()+1`。 - [x] 删除任务后序号不回收、不复用。 - [x] v12 存量任务按稳定顺序迁为独立 `cjN/cgN`，任务字段、状态、结果和创建人不变。 - [x] 有效 `task_claims`、`task_syb_sources` 全部指向新 ID，孤儿领取历史被清理。 - [x] v13 中断可重放；首次建库、v12 升级和重复迁移自检通过。 - [x] 列表、详情、搜索、领取、结果提交、失败提交都接受并使用新编号。 - [x] Client 四接口数量、路径和业务语义不变，Client 仍把任务 ID 当不透明字符串。 - [x] 成功采购仍保留 PDD 订单编号和下单时间，#169 重复采购门禁不受影响。 - [x] 固定 Go 1.23.0 全量测试、vet、构建通过，真实 MySQL 8.4 `_test` 库迁移和并发测试通过。 - [ ] 生产备份后迁移到 v13：存量为 `cj1…cj3`、`cg1…cg2`，下一号分别为 `cj4`、`cg3`，服务健康。（迁移与健康核对已完成；但 v13 在计划停服备份前被另一个连接生产库的当前源码进程提前触发，只生成了迁移后备份，交由用户验收此偏差。） ## 怎么验证 ```powershell Set-Location admin $env:GOTOOLCHAIN='go1.23.0' go test ./... -count=1 go vet ./... go build ./... ``` 另在独立 MySQL 8.4、库名以 `_test` 结尾的测试库验证首次建库、v12 升级、重复迁移、并发分配和关联完整性。生产部署后只读核对任务编号、任务结果、关联计数、schema、systemd 和公网健康状态。 ## 风险和回退 - 风险：Client 持有旧 ID 时会向旧路径提交。控制：生产没有活动采购；用户确认迁移后可清除 Client 本地任务再启动。 - 风险：主键重编号遗漏关联。控制：迁移前后逐表计数、引用完整性和成功采购结果结构自检。 - 风险：顺序号可枚举。说明：按客户确认规范实施；Client API 认证强化另行立项，不用随机 ID 代替认证。 - 回退：v13 会改写主键，代码回退必须同时恢复数据库备份，不允许只回退二进制。生产 v13 被提前触��后已生成并校验迁移后备份，且保留既有历史备份；具体偏差见完成记录。

ila referenced this issue

2026-08-12 08:57:54 +08:00

[Epic] Admin 采集采购管理端 #14

ila referenced this issue

2026-08-12 08:57:55 +08:00

[MVP] Admin 四模块可用闭环 #15

ila commented

2026-08-12 09:21:39 +08:00

????(2026-08-12)

??:???(????? MySQL 8.4 ????,????????)
????:9ad0675
???:MySQL schema v13?task_sequences ???????????/????/??????????????????? cjN / cgN?Admin/Client ??????????
?? MySQL 8.4:v12?v13??????16 ???????????????/????????
Client ????:26 ????
?????:?????? last_value ? MySQL 8.4 ?????,?????;??? current_value ????????
?? _test ????????????

## ????(2026-08-12) - ??:???(????? MySQL 8.4 ????,????????) - ????:`9ad0675` - ???:MySQL schema v13?`task_sequences` ???????????/????/??????????????????? `cjN` / `cgN`?Admin/Client ?????????? - ?? MySQL 8.4:v12?v13??????16 ???????????????/???????? - Client ????:26 ???? - ?????:?????? `last_value` ? MySQL 8.4 ?????,?????;??? `current_value` ???????? - ?? `_test` ????????????

ila commented

2026-08-12 09:28:18 +08:00

完成记录（待用户验收）

实现提交：9ad0675
归档提交：e80e021
归档：docs/task/172-任务主键改为采集采购独立序号.md
生产发布：/opt/cmautobuy/releases/9ad0675/cmautobuy-admin
生产结果：schema 13；采集序列 3、采购序列 2；5/5 编号合规；2/2 成功采购结果完整；无活动采购、孤儿领取历史或孤儿顺运宝来源；systemd active；本机和公网登录页 HTTP 200；启动后错误日志 0。
备份：已生成并校验迁移后备份 autobuy-after-v13-before-9ad0675-20260812T012426Z.sql.gz。

需要用户验收的偏差：计划中的“停服并生成迁移前备份”未能执行，因为生产 v13 已在计划部署前由另一个连接生产库的当前源码进程于 09:16 提前触发。发现后没有重复改号；已逐项确认这正是 #172 迁移且数据完整，再部署匹配 v13 的二进制。该项在验收清单中保持未勾选，其余项目已完成。

## 完成记录（待用户验收） - 实现提交：`9ad0675` - 归档提交：`e80e021` - 归档：`docs/task/172-任务主键改为采集采购独立序号.md` - 生产发布：`/opt/cmautobuy/releases/9ad0675/cmautobuy-admin` - 生产结果：schema 13；采集序列 3、采购序列 2；5/5 编号合规；2/2 成功采购结果完整；无活动采购、孤儿领取历史或孤儿顺运宝来源；systemd active；本机和公网登录页 HTTP 200；启动后错误日志 0。 - 备份：已生成并校验迁移后备份 `autobuy-after-v13-before-9ad0675-20260812T012426Z.sql.gz`。需要用户验收的偏差：计划中的“停服并生成迁移前备份”未能执行，因为生产 v13 已在计划部署前由另一个连接生产库的当前源码进程于 09:16 提前触发。发现后没有重复改号；已逐项确认这正是 #172 迁移且数据完整，再部署匹配 v13 的二进制。该项在验收清单中保持未勾选，其余项目已完成。

ila commented

2026-08-12 09:39:04 +08:00

Admin：任务主键改为采集 cj 与采购 cg 独立自增编号 #172

基本信息

要解决什么

做什么 / 不做什么

怎么做

验收标准

怎么验证

风险和回退

????(2026-08-12)

完成记录（待用户验收）

最新 HEAD 重新部署（2026-08-12）