 chengmaandCursor
|
417cd73afa
|
fix: 回写档口入库码时 t 固定为 0 (#278)
顺运宝把 t 绑成 Java Integer，毫秒时间戳溢出后 19 号回写全部失败。
Co-authored-by: Cursor <cursoragent@cursor.com>
|
2026-08-19 11:28:18 +08:00 |
|
|
chengma
|
b8f49fe4bb
|
fix: 多件档口入库码逐件回写 (#250)
|
2026-08-18 15:18:35 +08:00 |
|
|
chengma
|
b47e7ed9a9
|
fix: 档口入库码按货运单号直查顺运宝 (#245)
|
2026-08-15 16:27:03 +08:00 |
|
|
chengma
|
8e500606c5
|
fix: 合并多件档口入库码回写 (#240)
|
2026-08-15 14:27:31 +08:00 |
|
|
chengma
|
2778eed29f
|
feat: 安全回写档口入库码并支持核验恢复 (#234)
|
2026-08-15 09:10:10 +08:00 |
|
|
chengma
|
919522ff79
|
fix: 修复顺运宝分页总数误判 (#60)
|
2026-08-09 19:01:04 +08:00 |
|
|
chengma
|
05a54b044d
|
feat: 统一顺运宝日期同步并记录历史 (#59)
|
2026-08-09 18:22:58 +08:00 |
|
|
chengma
|
4b5cd13807
|
fix: 增强顺运宝同步完整性保护 (#58)
|
2026-08-09 17:17:42 +08:00 |
|
|
chengmaandClaude Opus 5
|
2e686b17a4
|
feat: 顺运宝登录接入验证码自动识别 (#47)
#46 的登录只有手工输验证码一条路，而会话 24 小时就过期——每天第一次
同步都得有人在场，将来也做不了定时同步。
docs/admin/08 §8 当时写死"不引入 OCR 服务"，理由是"多一个必须先启动的
东西"。那条判断基于示例脚本里的 http://127.0.0.1:8000/ocr（本机服务）。
用户提供了托管地址后前提不成立，本工单推翻它——文档里改写并保留原文，
让后来人知道这个决定变过、为什么变。
OCR 优先、手工兜底：识别成功直接登录，失败或服务不可达降级到 #46 已有的
手工弹窗，并在弹窗里说明是"已尝试 N 次"还是"服务不可用"。手工路径不删，
外部服务挂了不该让整个同步功能不可用。
识别失败也是 code:200。实测拿无文字图片探测 https://ocr.ilapage.cn/ocr
返回 {"code":200,"message":"Success","data":""}——不是错误码。所以
Recognize 只负责"这次 HTTP 调用有没有问题"，空 data 照常返回 (", nil)，
业务校验交给调用方；空 data 和长度不对收敛到同一个 len(code) != 4，
一条规则覆盖两种情况。
不合格的验证码不拿去登录：白费一次尝试，且频繁错误登录可能触发风控。
审查时变异测试发现这条没有测试守着——原测试只断言"重新取图了"和
"最终登录成功"，禁用长度校验后依然成立。已补 loginRecorder 记录每次
提交到 /am/auth/login 的 code，断言登录只被调用一次且提交的是合格的那个。
每次重试重新取图（同一张图再识别结果一样，且可能已被上次失败的登录作废）；
OCR 用独立 HTTP 客户端不带顺运宝 Cookie；验证码图片只在内存里传，不落盘。
OCR 不可达立即降级、不占用重试次数——对着连不上的地址重试 5 次，
操作员要等 50 秒才看到手工输入框，结果注定一样。
测试全部用 httptest，不打真实的 ocr.ilapage.cn 和 shunyunbaoerp.com。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-09 12:35:02 +08:00 |
|
|
chengmaandClaude Opus 5
|
5e426cacf6
|
feat: 顺运宝货运单同步 (#46)
顺运宝模块此前是骨架，「同步」点了提示"待接入"。5195 个蝦皮商品已经
进系统，但货运单（真实订单）一条都没有，后面的规格匹配无从谈起。
按接口契约（docs/admin/08，从 4 份 HAR 还原）实现：配置、登录（界面
手工输验证码）、会话缓存到 SQLite、按日期范围增量同步、落 syb_orders。
shopee_sku_id 绝不被同步覆盖。它是规格匹配的结果，顺运宝那边根本没有
这个值（只给 11 位商品ID，蝦皮規格ID 是 12 位）。同步写进去就是写空，
把人工攒的匹配成果洗掉且不报错。它只出现在 INSERT 列清单里，不在
DO UPDATE SET 里；repository 层和 service 端到端各有一个测试守着。
增量从「上次同步日期当天」重拉，不是第二天。created 筛选粒度是日期而
last_synced_at 精确到秒，从第二天拉会漏掉当天晚些时候创建的单且不报错。
宁可重复拉（upsert 幂等）也不能漏。中途失败不更新 last_synced_at，
否则下次跳过这段区间，漏的单永远补不回来。
日期运算用 UTC+8，不是 UTC。审查时从 HAR 确认 created 是当地时间：
抓包于 2026-07-28T03:31:45Z（= 11:31 UTC+8），同一响应里 created 是
"2026-07-28 10:37:59"；若它是 UTC 则等于 18:37 UTC+8，比抓包晚 7 小时，
订单创建于未来，不成立。用 UTC 算会在本地 00:00-08:00 把"今天"算成昨天，
当天早晨的单这轮拉不到。用 time.FixedZone 写死，不用 LoadLocation——
那要读系统 tzdata，Windows 默认没有，打包成 exe 会失败。
金额一律取 detail/listByStock 的值：08 §5.1 实测同一响应里 amtOrder
在列表接口是分、escrowAmount 却不是，单位不统一，取错差 100 倍。
迁移 v5 纯追加（syb_session、syb_sync_state、syb_orders.product_spec），
v1-v4 逐字未动，CheckSchema 覆盖新表新列。
会话有效性判断把「网络故障」和「明确未登录」的分类集中在 Client.do()
一处——网络抖一下就判定登出的话，验证码会弹个不停，还会丢掉有效会话。
测试全部用 httptest 假服务端，不打真实站点。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
2026-08-09 11:49:13 +08:00 |
|