break
6333f4ad13
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 9m57s
- 提交写事务内先取事务级 advisory lock，再校验既有未删除账号/店铺与其它待审批申请： 手机号 1014、用户名 1013、店铺编号 1031、待审批占用 1007，冲突不落库且不消费短信验证码 - 已驳回（含通过后撤销）与已通过的终态记录不阻塞重新注册，形成新记录与新审批实例 - 并发同关键字段提交串行裁决，同一关键字段至多一条待审批记录 - 审批通过建店建号前复检关键字段，冲突返回可定位错误并整体回滚，不再以裸数据库错误收场 - 归档 Change fix-agent-distribution-registration-duplicate-guard 并同步主 Spec 验证：junhong_cmp_test + Redis DB 6 受控脚手架 37 项通过 / 0 项失败（含 6 路并发仅 1 条落库、 审批冲突回滚与无冲突建店回归），清理后 fixture 残留 0；gofmt/go build/go vet 全绿； openspec validate --all 35 项通过、doctor healthy、context-health 通过
2.8 KiB
2.8 KiB
Why
公开扫码注册接口 POST /api/c/v1/agent-distribution-registrations 在创建待审批注册记录前只做格式校验，不校验手机号、用户名、店铺编号是否已被既有账号/店铺占用，也不校验是否已存在其它待审批申请。后果是：重复提交会同时生成多条待审批记录与企业微信审批单；企业微信通过其中一条后建店建号必然撞 tb_account/tb_shop 唯一索引，整笔审批事务回滚，形成「审批已通过、店铺和账号没建出来」且注册记录永久停留在待审批的漏水场景——即测试库当前 7 条待审批记录中出现手机号、用户名、店铺编号重复（SHOP20260729114608DDUQ、csdp333-1、罗洋平 各重复）所暴露的问题。
What Changes
- 校验位置前移到「创建注册记录与审批实例」的同一写事务内：手机号、用户名、店铺编号与既有未删除账号/店铺冲突时拒绝，返回既有稳定错误码
1014 手机号已存在、1013 用户名已存在、1031 店铺编号已存在。 - 手机号、用户名、店铺编号与其它
status=0待审批注册记录冲突时拒绝，返回1007 资源冲突与可定位中文提示（区分手机号 / 用户名 / 店铺编号）。 - 已驳回（
status=2，含企业微信通过后撤销按驳回处理）与已通过（status=1）的历史注册记录 MUST NOT 阻止同一手机号、用户名或店铺编号重新提交：填错资料后重新扫码注册仍可用。 - 同一关键字段的并发提交由事务级 advisory lock 串行裁决，保证至多落一条待审批注册记录；锁在事务提交时自动释放。
- 审批通过路径在创建店铺与账号前复检同一组关键字段，冲突时返回可定位错误（既有账号/店铺占用）并整体回滚，不再以裸数据库错误收场。
- 冲突拒绝发生在注册记录落库前，短信验证码 MUST NOT 被消费，客户修正资料后可直接用同一验证码重试。
- 路由描述（
internal/routes/agent_distribution_public.go）同步新增失败原因；docs/admin-openapi.yaml随之重新生成。
明确不做：不校验店铺名称重复（tb_shop 无 shop_name 唯一约束，重名是既有允许行为）；不新增数据库唯一索引（待审批唯一性是跨状态条件约束，需在应用事务内串行裁决，且现存重复待审批行会让条件唯一索引迁移失败）；不新增错误码；不改变注册记录、审批实例与审批通过建实体的既有结构与语义。
Capabilities
New Capabilities
无。
Modified Capabilities
agent-distribution-withdrawal: 「分销码与待审批代理注册」需求新增关键字段唯一性门禁（既有账号/店铺、其它待审批申请）、驳回后重新注册不被阻塞、并发提交串行化与审批通过前复检。