Admin：修复档口入库码回写 t 参数溢出 Integer #278

New Issue

2026-08-19T11:20:57+08:00

ila commented

2026-08-19 11:20:57 +08:00

基本信息

类型：缺陷
父级大工单：#14
所属 MVP / 版本：#224 / 档口入库码回写 MVP
阶段：阶段 11：写码参数 Integer 溢出修复（2026-08-19）

要解决什么

2026-08-19 档口入库码回写全部失败，典型错误：

已确认 0/1 件；写入第 1 个单件入库码失败，系统不会自动重试：
顺运宝接口 /am/stock/detail/updateDetailCode 业务失败:
msg=Can not parse the parameter "1787108752485" to Integer value. code="-1"

"1787108752485" 换算为 2026-08-19 11:05:52.485 CST，就是请求发出时的毫秒时间戳，不是档口入库码，也不是货运单 id。

根因：#250 把 updateDetailCode 的查询参数 t 从 #234 的 "0" 改成 time.Now().UnixMilli()。顺运宝把 t 绑成 Java Integer（上限 2147483647）。当前毫秒是 13 位，必然溢出，所以每条回写都在真正写 code 之前被拒。远端一码都没写上，所以是「已确认 0/1 件」。

时间线：

#234：GET .../updateDetailCode?t=0&id=...，t 固定 "0"。
#250（8/18 15:18）：改为 POST，t 改为当前毫秒。
#269（8/18 15:39）把该二进制切到生产，部署记录写明没有做过真实回写。
8/19：第一次用新二进制对当天单回写，全部同一类失败。

「系统不会自动重试」是既定门禁，不是第二处故障。

做什么 / 不做什么

做：UpdateDetailCode 的 t 改回固定 "0"，并让测试断言就是 "0"，不能只断言非空。
做：同步修正 docs/admin/08-顺运宝接口.md 的写码契约，写明 t 必须能进 Java Integer，以及 #250 毫秒时间戳为什么不能再用。
不做：不把 t 改成 Unix 秒。秒目前能进 Integer，但 2038 年仍会溢出；防缓存不是这个写接口的契约，t=0 才是 #234 已通过参数绑定的值。
不做：不省略 t。#234 一直带 t=0；省略可能走到另一个绑定路径，没有生产证据。
不做：不把方法改回 GET。19 号失败已经进到业务失败信封，说明 POST 路由是通的；本工单只修 t，避免把方法和时间戳两个契约混在一次最小修复里。
不做：不改 createDetail、deleteInnerCode、匹配、排队、检查点、数据库、页面和 Client 接口。
不做：不自动重放 19 号失败记录。写动作只允许一次；业务失败已明确、远端未写入。修复上线后由操作员重新勾选回写。
不做：本工单不部署生产。

怎么做

已确认方案：恢复 #234 的 t=0，保留 #250 的 POST。

预计修改文件：

admin/syb/client.go：UpdateDetailCode 把 t 从 UnixMilli() 改回 "0"，注释写清防的是 Integer 溢出，不是优化。
admin/syb/client_test.go：写码请求必须断言 t=="0"；13 位毫秒时间戳视为失败。
docs/admin/08-顺运宝接口.md：契约改回 t=0，并记录 #250 回归原因。

不动数据库，不改 Admin/Client HTTP 契约，不改采购下单。

验收标准

UpdateDetailCode 发出的查询参数 t 固定为 "0"，不再调用 UnixMilli 或 Unix。
自动化测试断言 POST /am/stock/detail/updateDetailCode 的 t 等于 "0"；只断言非空不算通过。
id、detailId、code 和方法仍为 POST，单次发送门禁不变。
docs/admin/08-顺运宝接口.md 写明 t=0 及不得再传毫秒时间戳的理由。
固定 GOTOOLCHAIN=go1.23.0 下 go test ./syb -count=1、go test ./... -count=1、go build ./...、go vet ./... 通过。
未向真实顺运宝发送写请求；未改 19 号失败记录状态。

怎么验证

全部从 admin/ 执行：

$env:GOTOOLCHAIN="go1.23.0"
go test ./syb -run InnerCodeWrite -count=1
go test ./... -count=1
go build ./...
go vet ./...
Remove-Item Env:GOTOOLCHAIN

预期：UpdateDetailCode 相关测试通过，且失败输出里不能再出现 t 为 13 位数字。本工单不连生产顺运宝、不部署。

风险和回退

风险：这是顺运宝写码接口。若线上页面其实依赖非零 t 做防缓存，改回 t=0 后理论上可能被中间层缓存；当前失败已经证明毫秒 t 进不了 Integer，而 #234 的 t=0 能完成参数绑定。
风险：修完前不要对 19 号失败记录自动重试；那些请求在参数绑定阶段被拒，远端未写入，修复发布后由操作员重新勾选即可。
回退：还原本工单对 client.go、测试和 08 文档的三处修改即可，无数据库迁移。

## 基本信息 - 类型：缺陷 - 父级大工单：#14 - 所属 MVP / 版本：#224 / 档口入库码回写 MVP - 阶段：阶段 11：写码参数 Integer 溢出修复（2026-08-19） ## 要解决什么 2026-08-19 档口入库码回写全部失败，典型错误： ```text 已确认 0/1 件；写入第 1 个单件入库码失败，系统不会自动重试：顺运宝接口 /am/stock/detail/updateDetailCode 业务失败: msg=Can not parse the parameter "1787108752485" to Integer value. code="-1" ``` `"1787108752485"` 换算为 `2026-08-19 11:05:52.485 CST`，就是请求发出时的毫秒时间戳，不是档口入库码，也不是货运单 id。根因：#250 把 `updateDetailCode` 的查询参数 `t` 从 `#234` 的 `"0"` 改成 `time.Now().UnixMilli()`。顺运宝把 `t` 绑成 Java `Integer`（上限 `2147483647`）。当前毫秒是 13 位，必然溢出，所以每条回写都在真正写 `code` 之前被拒。远端一码都没写上，所以是「已确认 0/1 件」。时间线： - #234：`GET .../updateDetailCode?t=0&id=...`，`t` 固定 `"0"`。 - #250（8/18 15:18）：改为 `POST`，`t` 改为当前毫秒。 - #269（8/18 15:39）把该二进制切到生产，部署记录写明没有做过真实回写。 - 8/19：第一次用新二进制对当天单回写，全部同一类失败。「系统不会自动重试」是既定门禁，不是第二处故障。 ## 做什么 / 不做什么 - 做：`UpdateDetailCode` 的 `t` 改回固定 `"0"`，并让测试断言就是 `"0"`，不能只断言非空。 - 做：同步修正 `docs/admin/08-顺运宝接口.md` 的写码契约，写明 `t` 必须能进 Java Integer，以及 #250 毫秒时间戳为什么不能再用。 - 不做：不把 `t` 改成 Unix 秒。秒目前能进 Integer，但 2038 年仍会溢出；防缓存不是这个写接口的契约，`t=0` 才是 #234 已通过参数绑定的值。 - 不做：不省略 `t`。#234 一直带 `t=0`；省略可能走到另一个绑定路径，没有生产证据。 - 不做：不把方法改回 GET。19 号失败已经进到业务失败信封，说明 POST 路由是通的；本工单只修 `t`，避免把方法和时间戳两个契约混在一次最小修复里。 - 不做：不改 `createDetail`、`deleteInnerCode`、匹配、排队、检查点、数据库、页面和 Client 接口。 - 不做：不自动重放 19 号失败记录。写动作只允许一次；业务失败已明确、远端未写入。修复上线后由操作员重新勾选回写。 - 不做：本工单不部署生产。 ## 怎么做已确认方案：恢复 `#234` 的 `t=0`，保留 `#250` 的 POST。预计修改文件： - `admin/syb/client.go`：`UpdateDetailCode` 把 `t` 从 `UnixMilli()` 改回 `"0"`，注释写清防的是 Integer 溢出，不是优化。 - `admin/syb/client_test.go`：写码请求必须断言 `t=="0"`；13 位毫秒时间戳视为失败。 - `docs/admin/08-顺运宝接口.md`：契约改回 `t=0`，并记录 #250 回归原因。不动数据库，不改 Admin/Client HTTP 契约，不改采购下单。 ## 验收标准 - [ ] `UpdateDetailCode` 发出的查询参数 `t` 固定为 `"0"`，不再调用 `UnixMilli` 或 `Unix`。 - [ ] 自动化测试断言 `POST /am/stock/detail/updateDetailCode` 的 `t` 等于 `"0"`；只断言非空不算通过。 - [ ] `id`、`detailId`、`code` 和方法仍为 POST，单次发送门禁不变。 - [ ] `docs/admin/08-顺运宝接口.md` 写明 `t=0` 及不得再传毫秒时间戳的理由。 - [ ] 固定 `GOTOOLCHAIN=go1.23.0` 下 `go test ./syb -count=1`、`go test ./... -count=1`、`go build ./...`、`go vet ./...` 通过。 - [ ] 未向真实顺运宝发送写请求；未改 19 号失败记录状态。 ## 怎么验证全部从 `admin/` 执行： ```powershell $env:GOTOOLCHAIN="go1.23.0" go test ./syb -run InnerCodeWrite -count=1 go test ./... -count=1 go build ./... go vet ./... Remove-Item Env:GOTOOLCHAIN ``` 预期：`UpdateDetailCode` 相关测试通过，且失败输出里不能再出现 `t` 为 13 位数字。本工单不连生产顺运宝、不部署。 ## 风险和回退 - 风险：这是顺运宝写码接口。若线上页面其实依赖非零 `t` 做防缓存，改回 `t=0` 后理论上可能被中间层缓存；当前失败已经证明毫秒 `t` 进不了 Integer，而 `#234` 的 `t=0` 能完成参数绑定。 - 风险：修完前不要对 19 号失败记录自动重试；那些请求在参数绑定阶段被拒，远端未写入，修复发布后由操作员重新勾选即可。 - 回退：还原本工单对 `client.go`、测试和 `08` 文档的三处修改即可，无数据库迁移。

ila referenced this issue

2026-08-19 11:21:15 +08:00

[MVP] Admin 档口入库码回写 #224

ila referenced this issue

2026-08-19 11:21:16 +08:00

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

ila commented

2026-08-19 11:23:35 +08:00

实施记录

代码已按工单改完，尚未提交、尚未部署。

改动：

admin/syb/client.go：UpdateDetailCode 的 t 改回固定 "0"。
admin/syb/client_test.go：断言 t=="0"，不再只检查非空。
docs/admin/08-顺运宝接口.md：契约改回 t=0，并写明 Integer 溢出原因。

验证（admin/，GOTOOLCHAIN=go1.23.0）：

go test ./syb -run InnerCodeWrite -count=1  → ok
go test ./... -count=1                      → ok
go build ./...                              → 通过
go vet ./...                                → 通过

未验证：未向真实顺运宝发送写请求；未改 19 号失败记录状态；未部署生产。修复上线后由操作员重新勾选回写，不自动重试。

## 实施记录代码已按工单改完，尚未提交、尚未部署。改动： - `admin/syb/client.go`：`UpdateDetailCode` 的 `t` 改回固定 `"0"`。 - `admin/syb/client_test.go`：断言 `t=="0"`，不再只检查非空。 - `docs/admin/08-顺运宝接口.md`：契约改回 `t=0`，并写明 Integer 溢出原因。验证（`admin/`，`GOTOOLCHAIN=go1.23.0`）： ```text go test ./syb -run InnerCodeWrite -count=1 → ok go test ./... -count=1 → ok go build ./... → 通过 go vet ./... → 通过 ``` 未验证：未向真实顺运宝发送写请求；未改 19 号失败记录状态；未部署生产。修复上线后由操作员重新勾选回写，不自动重试。

ila referenced this issue

2026-08-19 11:29:01 +08:00

Admin：部署档口入库码 t=0 修复到生产 #279

ila commented

2026-08-19 11:29:10 +08:00