dachui/order_site
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
1,017 Commits 3 Branches 0 Tags
b70741daecf7406f1caa11c22bb230a709038f9b
Commit Graph
42 Commits
Author SHA1 Message Date
yml2213 56a8184576 feat(douyin-mashida): 皮肤自动发货（按内部 SKU 分流 + 领取链接 + 买家领取接口） 
抖音码速达的皮肤类商品改为「自动发货 + 领取链接」：买家不用输订单号，点链接直接领。

**分流（按内部 SKU）**
- 平台闸门放行 `provider='douyin_mashida' && platform='doudian'`，走**独立分支**
  （原有 91/快手路径一行未动，避免外溢）
- 判据：内部 SKU（`sku_order_list[].code`，即 order_items.sku_code）命中权威表
  `AFFILIATE_DASH_SKU_MAPPING` → 新执行器 `douyin_mashida_skin`；未命中 → `manual_dispatch`
- 皮肤判定与商品图同源（都用那张权威表），保证「能路由 ⇒ 有图」
- 履约路由新增 `internal_sku` 匹配维度（`rules[].internalSku`，NFKC+去空白+小写，exact/contains）；
  旧规则缺 `matchField` 时默认 `product_name`，**归一化/优先级/回退顺序完全不变**

**执行器与领取 token**
- 新增 `douyin-mashida-skin-executor`：建 claim token、置 `link_generated/pending_claim`，
  `resolveDeliveryLink` 返回本站路径式领取链接；注册进 registry、planner 分支、
  bootstrap 种子 profile（`抖音皮肤自动发货`）；进 `ROUTABLE_EXECUTOR_KEYS`
- token 粒度 = 一个履约单元一个（`claim_tokens.task_id` 唯一）；一单多项时
  cert_link/买家消息取 task id 最小的那个并告警

**cert_link 与发消息**
- 皮肤订单且该订单项已有 token 且配了 `claimLinkBase` → `cert_link = claimLinkBase/token`；
  其它情况一律用 `certLink`（老行为不变）
- 领取链接**只认** `claimLinkBase`，绝不回退 `buildClaimUrl`/`orders.claimBaseUrl`
  （那是 hash 形式的打手领取页，语义不同）
- 付款建单+发券成功后按 `messageTemplate`（`{link}/{sku}/{orderNo}/{productTitle}`）
  经 `order.message` 发给买家；best-effort，失败只记 warn

**买家领取接口**
- `GET/POST /api/v1/claim-skin/:token`（限流、公开）；详情含内部SKU/引流标题/商品图/
  数量/金额/支付时间/动态表单字段；token 失效给明确 errorCode（404/410/409），不打 500
- 提交账号：先核销平台券再落记录（避免「记账了但券没核销」的资损），已提交幂等

**隐私**
- 买家游戏账号落 `fulfillment_tasks.claim_submission_json`（迁移 096），
  **不进** `work_orders.material_json`（那是发给打手的素材）；详情接口不返回券码明文/手机号/地址/open_id
 2026-10-09 15:06:43 +08:00
yml2213 ecc8ffaee4 fix(douyin-mashida): 出网响应按大整数安全解析（product_id 被压精度） 
真实联调发现：抖店大量 id 是 19 位数字，超过 Number.MAX_SAFE_INTEGER，
入站推送我们用 express.text() 收原文保住了精度，但**出网响应是 JSON.parse 出来的**，
19 位数字在解析瞬间就被压成相邻 double：

  平台真值 product_id = 3847255376114352567
  我们存到的          = 3847255376114352600

后果：拿这个 product_id 去调 product.detail 报「商品不存在」（实测），
任何按商品ID做的映射/查询都会错。

修复：抖音出网响应改用共享的 parseJsonObject(..., { preserveLargeIntegers: true })。
utils/json.ts 里其实早有 wrapLargeIntegerLiterals（≥16 位/超 MAX_SAFE_INTEGER 才包裹，
只处理值位置的整数字面量，不误伤字符串内数字与短数字），但全仓没有调用方 —— 现在接上。

实测：同一笔订单 product_id 已精确为 …567，product.detail 返回 code=10000 并拿到商品图。
补了 json 解析的大整数单测（含「字符串里的数字、短数字不受影响」的反例）。
 2026-10-09 14:47:55 +08:00
yml2213 90de6b9419 perf(worker): 单号检索收敛为可走索引的等值/前缀，并支持关联单号反查 
问题：后台「按单号检索」在平台单号/工单号分支里 OR 了一支
`work_order_no ILIKE '%'||$n||'%'`。前置通配符非 sargable，任何 B-Tree 都用不上，
整条查询退化成 work_orders 的 Seq Scan。

生产实测（10.3 万行 / 572MB，pg_stat_statements 46 小时窗口）：
  - 列表查询 + 统计查询用同一份 filters 并行执行，一次检索打两遍全表；
    两者合计占全库 66% 的磁盘读（1.1TB/46h），单次读 26,442 个块（约 211MB）、398ms、返回 1 行。
  - 收敛后同库同参数：等值 0.19ms，前缀 30ms（约 2000 倍）。
  - 真实统计查询端到端 760ms → 61.6ms。

改动：
1. 平台单号/工单号分支收敛为「等值 + 前缀」，与 order-repo / task-repo 既有写法一致；
   工单号含随机小写段（10.2 万行里 7.4 万行非全大写），保留 LOWER() 比较。
2. 迁移 090 补 text_pattern_ops 前缀索引：当前库 collation 为 en_US.utf8，
   前缀 LIKE 在默认 B-Tree 上会退化成全索引扫（实测 438ms）。
3. 新增关联单号反查分支：SUB/INV/AS/DT 不在 work_orders 上，
   经关联表反查工单 id，四条链路均命中唯一索引。
4. 前端 isExplicitOrderNoSearch 同步补齐（否则搜到的单会被状态页签挡掉、
   实时补丁还会把行删掉）。

验证：生产 EXPLAIN 逐条比对 + 14 项仓储单测 + 6 项分类器单测。
 2026-10-03 14:27:32 +08:00
yml2213 5e59a5fdb1 fix(order-service): 修复包含 Emoji 和孤立代理字符的订单在 PostgreSQL jsonb 下报错导致死循环重试进单的问题 
1. 在 utils/json.ts 新增 sanitizeWellFormedUnicode、deepSanitizeUnicode 和 safeJsonStringify，自动清理空字节 (\0) 并将畸变孤立 UTF-16 代理字符 (Lone Surrogates) 安全转换为规范字符，杜绝 PostgreSQL jsonb 解析错误；
2. 拼多多订单映射器与通用进单服务 (order-service) 全面接入 Unicode 深度清洗与安全序列化，确保买家昵称/留言中的各类特殊 Emoji 和生僻字符平滑落库；
3. 数据库仓储层 (order-repo / order-item-repo) 针对 raw_payload_json、spec_json、item_snapshot_json 等 jsonb 字段增加兜底安全序列化保护；
4. 补充 utils/json.test.ts 与 pdd-order-mapper.test.ts 单元测试，覆盖畸变字符与空字节场景。
 2026-09-19 11:40:02 +08:00
yml2213 f816f57eb0 fix(worker-platform): 补齐寄售凭证类型导入与平台单号测试格式化 
1. 修复 consignment-worker-service.ts 缺少 WorkOrderRow 类型导入的问题；
2. 规范化 platform-order-id.test.ts 与 worker-platform-service.test.ts 代码风格。
 2026-09-18 19:40:29 +08:00
yml2213 d6523635ea fix(worker-platform): 优化工单号精准检索与跨状态流转展示，修复状态更新后工单消失问题 
1. 后端查询重构：新增 isWorkOrderNoLookupKeyword 工单号前缀与忽略大小写精准索引匹配，优化后端 work-order-query-repo 的工单号检索路径；
2. 前端单号智能穿透：管理员输入 WO... 等精准单号查询时，自动放宽细粒度排他状态/阶段过滤，避免加好友/验收等状态流转后工单因旧状态筛选脱靶消失；
3. 搜索栏交互升级：输入框清空即时重置关键词与页码，支持回车/按钮/清除全方位无缝触发；
4. 详情抽屉与多面板联动：增加 ordersQuery 数据更新对 detailOrder 的自动同步，并将 refreshAll 广播范围覆盖至寄售仓库与统计指标。
 2026-09-18 19:36:17 +08:00
yml2213 7672360875 Merge branch 'main' into dev 2026-09-15 14:17:36 +08:00
yml2213andCursor 2e197f93e0 fix(claim): 透出 affiliate_dash 上游错误，便于排查提交 UID 失败 
上游 4xx 不再一律打成 502 兜底文案；affiliate_dash 依赖错误优先展示真实 message。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 11:51:32 +08:00
yml2213andCursor 5cbb977b96 fix(pdd): 匹配诊断对齐 out_sku_sn，并加速拼多多订单号搜索 
匹配测试/结构化规则补读商家编码，诊断日志标出缺失字段；订单/任务/工单关键词支持带连字符的 PDD order_sn 走索引快路径。

Co-authored-by: Cursor <cursoragent@cursor.com>
 2026-09-15 10:45:53 +08:00
yml2213 1aa6dba931 feat(consignment): 新增和平精英寄卖库存管理、定向收集审核与工单智能匹配履约 2026-09-14 11:39:15 +08:00
yml2213 fea82bff36 style(backend): 格式化代码并修复floating-promises以通过pre-push检查 2026-09-12 17:46:47 +08:00
yml2213 71912ef5d0 feat(worker-platform): 接单平台全面改用内部统一工单号，隐藏第三方平台单号防泄漏 
1. 新增业务工单单号生成器 generateWorkOrderNo()，生成 WO+年月日+时分+随机数的统一内部单号（如 WO26091216358821）；
2. 接单平台抢单大厅、订单列表、详情抽屉、模态弹窗及售后全面切换为展示 workOrderNo，彻底屏蔽拼多多/快手等第三方平台来源标识；
3. 打手资金明细补充关联内部工单号 relatedWorkOrderNo，避免打手在账单中识别原平台；
4. 管理后台工单面板升级为双单号清晰展示（高亮内部工单号 + 辅助可复制平台单号），兼顾打手对单与官方平台售后溯源。
 2026-09-12 16:44:59 +08:00
yml2213 ffb71f2276 修复接单端过期会话重复请求 2026-08-30 17:32:34 +08:00
yml2213 25b89bb503 优化：降低访问日志噪声并增加日志文件轮转 2026-08-30 16:59:11 +08:00
yml2213 70b31f4874 SSE鉴权失效停止重连清理会话跳登录并降噪4xx错误日志 2026-08-23 11:01:41 +08:00
yml2213 5c7c3e14e3 统一前后端代码格式化配置 2026-08-16 17:27:12 +08:00
yml2213 c138d75d8e 快手发码通知采集到独立日志文件，修复 integration 日志阈值问题 2026-08-02 11:43:17 +08:00
yml2213 01f46e4fc7 对接日志默认仅记录告警与错误 
新增 LOG_INTEGRATION_LEVEL（默认 warn），压低 integration-*.log 体积；
失败类文案自动提升为 error，避免异常被过滤。
 2026-07-10 21:17:55 +08:00
yml2213 042574dea3 继续收紧 TypeScript：ClaimIdentity 契约与 flow 出口类型 
- 新增 types/claim-identity，统一 ClaimIdentity / Payload / AdminSummary
- 导出 KuaishouCloudFlow、KuaishouFeifeiFlow 作为 normalize 出口
- 生产路径 JsonObject 统一从 types/json 导入，去掉 rebind as any
- 前后端 claimIdentity 类型字段对齐
 2026-07-10 15:56:25 +08:00
yml2213 8bcd9bbd81 收紧后端 TypeScript：统一 Json 类型与 TaskContext 契约 
关闭 allowJs；集中 JsonObject 定义并替换分散 any 别名；parseTaskContext 返回 TaskContext；任务详情 API 标注 AdminTaskDetailView；测试减少 as any。
 2026-07-10 15:52:05 +08:00
yml2213 59f6f5ee1e 增加feifei 日志 2026-07-07 16:04:54 +08:00
yml2213 bd0368f91e 修复无法兑换bug 2026-05-29 17:28:19 +08:00
yml e4c9873c8d 优化日志切分和保留策略 2026-05-28 12:32:13 +08:00
yml2213 7aef1a6d50 开启后端严格空值检查 2026-05-26 08:45:06 +08:00
yml2213 dea3023825 优化后端鉴权与日志安全 2026-05-26 08:21:11 +08:00
yml 2c7464b1eb 删除库存和旧回调管理 2026-05-25 23:07:19 +08:00
yml 38c6323649 清理旧启动状态 2026-05-25 22:15:35 +08:00
yml 0e6bf88beb [Snow Team] express-types: auto-commit work 2026-05-21 22:57:48 +08:00
yml 5a5bcea904 [Snow Team] core-infra: auto-commit work 2026-05-21 22:23:08 +08:00
yml 589de4b50b deduplicate json config file access 2026-05-21 18:54:41 +08:00
yml 17a615b8de deduplicate task parsing and masking helpers 2026-05-21 18:50:07 +08:00
yml acd5c0d50e 后端迁移测试文件 2026-05-21 17:39:34 +08:00
yml 78e9d1d5c5 后端迁移入口与迁移脚本 2026-05-21 17:35:01 +08:00
yml f43101c080 后端迁移基础工具层 2026-05-21 15:50:49 +08:00
yml 1476522ab5 后端建立 TypeScript 构建链路 2026-05-21 13:36:38 +08:00
yml 66261e56d1 ts类型检查 2026-05-04 09:43:38 +08:00
yml 9636167177 优化 Webhook 列表, 优化日志系统 2026-04-14 20:02:37 +08:00
yml df2eb34478 彻底重构-1 2026-04-09 09:06:08 +08:00
yml e4ab1f559e 优化了一些文件 增加多店铺 2026-04-09 01:31:47 +08:00
yml c2ec3aa6d2 可以接收到咸鱼的订单创建连接 2026-04-08 23:20:21 +08:00
yml a2b09c89e8 开始多平台 多店铺整改 2026-04-08 22:21:11 +08:00
yml 313c036845 init 2026-04-08 16:30:42 +08:00