wx/hl-api-changelog

派生 0

文件

T

Mimingguang 8e72e63879

changelog-filename-gate / validate (push) Failing after 2s

详情

chore(changelog): #8023/#7965/#8003/#8004 前端实证翻 not_required(grep 零消费面/自动受益);#7443 到件维持 pending 挂起

2026-09-20 16:09:06 +08:00

7.7 KiB

原始文件 Blame 文件历史

schema, ticket, title, consumer, author, change_type, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base

schema	ticket	title	consumer	author	change_type	backend_status	gateway_status	frontend_status	frontend_owner	frontend_ref	target_release	verified_at	status_note	updated_at	base
hl-changelog/v2	8003	团期车辆共用关系：跨维度确认后成员行跟随最新派单行 + 新增每日悬挂核对任务 1045（无接口契约变更）	admin	jw(GIT)	修复	deployed	verified	not_required					本单没有新增、修改、删除任何 admin/mp 端点，请求参数与响应字段全部不变，change_type 取「修复」是按 20_7539 先例（校验器只允许新增接口/修改接口/删除接口/修复/前端* 几类，接口三类要求逐端点模板而本单无 admin 端点可列）。唯一新增的是 Quartz 桥接用的内部端点 POST /internal/fleet/jobs/share-member-dangling-reconcile/run，只由 hl-user-service 的定时任务经 X-Internal-Token 调用，不经网关、前端不可达，故不单列后端 changelog 条目。gateway_status=verified 指共用关系确认端点 POST /admin/fleet/group-dispatch/batches/{groupBatchId}/share-groups 经测试网关实测通过（2026-09-20 在团期 2101174125761265666 上连建车、司机两个维度的关系，库内复核两组成员行均指向同一张最新派单行）。frontend_status=not_required：响应字段与结构不变，前端无需改调用；但 members[].sourceId 的取值行为变了（见第二节），任何把它缓存/固化的前端逻辑需要复核。前端实证维持 not_required(mmg 2026-09-20):share-groups/shareGroups 全仓零命中,共用关系功能前端未接入(#7444 交接件未到件),members[].sourceId 取值行为变化零消费面;无缓存/固化该值的逻辑。	2026-09-20	dev-v3

fleet: 团期车辆共用关系跨维度确认后成员行跟随最新派单行 + 每日悬挂核对任务 1045

服务: hl-fleet-service（改绑与核对逻辑）/ hl-user-service（任务注册 1045） PR: #8029 Issue: #8003 日期: 2026-09-20 影响范围: 无对外接口变化；共用关系详情里 members[].sourceId 在跨维度确认后会指向最新那张派单行

⚠️ 关键变化

本单没有任何可调用的新接口：admin 侧没有新增、修改、删除端点，请求参数、响应字段、枚举、路径全部不变。
同一批成员先后建「车维度」和「司机维度」两个共用关系时，两个关系的成员身份现在指向同一张派单行。此前第二次确认只更新它自己那个维度，先建的那个维度会一直指着一张已经作废的派单。
新增每日定时任务 1045「共用关系成员悬挂核对」（每天 04:10），只巡检、只记日志，不改任何业务数据。
前端不需要改任何调用，但要知道：GET /admin/fleet/group-dispatch/batches/{groupBatchId}/share-groups 返回的 members[].sourceId 会在成员被重新派车后换成新值，不能把它当成稳定标识长期缓存。

一、原先的现象

确认共用关系时，如果某个成员当前还没占着这辆共用车（或这名共用司机），后端会替它走一次改派把它派进来。改派是「作废旧的派车记录、生成一张新的」，派车记录的 ID 必然换新。

一户成员可以同时在两个关系里：一个是「共用这辆车」，另一个是「共用这名司机」。过去第二次确认只把它自己那个维度的成员身份更新成新的派车记录，先建的那个维度仍记着旧的那张 ——而旧的那张此刻已经作废。结果是：

关系的成员名单里挂着一个已经不存在的派车记录；
这户真正在跑的那张派车记录，反而不在那个关系的成员名单里。

对使用者当时不可见（冲突校验会跳过已作废的记录，所以不会误判、不会报错），但凡是按「这个关系有几个成员」计数的地方都会多算一个。

二、现在的行为

场景	原来	现在
先建车维度关系，再建司机维度关系	车维度成员仍指向被作废的派车记录	两个维度的成员都指向同一张、当前在跑的派车记录
关系详情里的 `members[].sourceId`	可能是一个已作废的派车记录 ID	始终是当前在跑的那张
关系的活跃成员数	可能把同一户算两次（旧 ID 一次、新 ID 一次）	与真实成员数一致

响应结构没有任何变化，变的是 members[].sourceId 的取值：

// GET /admin/fleet/group-dispatch/batches/2101174125761265666/share-groups?serviceDate=2027-01-06
// 车维度关系（359966491308855296）——下面这个 sourceId 就是修复后的取值
{
  "code": 200,
  "message": "成功",
  "data": [
    {
      "shareGroupId": "359966491308855296",
      "resourceType": "VEHICLE",
      "resourceId": "2065329519232720897",
      "status": "ACTIVE",
      "members": [
        { "sourceType": "GROUP_DISPATCH", "sourceId": "2101174278589190146", "requirementId": null,             "orderId": null },
        { "sourceType": "ASSIGNMENT",     "sourceId": "359966520803201024",  "requirementId": "7330996163649609", "orderId": "2101174125723516929" }
      ]
    }
  ]
}

修复前这一格会停在 359966492122550272（已作废的那张），修复后是 359966520803201024（当前在跑的那张），与司机维度关系里那一格完全相同。

给前端的一句话：sourceId 是「这户当前挂的那张派车记录」，会随改派变化；要长期标识一户成员请用 requirementId（用车需求 ID，跨改派不变）或 orderId。

三、新增定时任务 1045「共用关系成员悬挂核对」

任务	时间	做什么	会不会改数据
1045 共用关系成员悬挂核对	每天 `04:10`	巡检全部在关系里的成员，找出那些指向已作废/已不存在派车记录的	不会，只记日志并返回条数

只发现、不处置：一条这样的记录，可能该改绑到新的派车记录、也可能该退出关系，从记录本身分辨不出，自动猜错方向会把车务人工确认过的关系悄悄改掉。所以任务只把它们报出来，由人处置。
任务的结果在 fleet 服务日志里按关系汇总（共用关系存在悬挂成员行: shareGroupId=... 悬挂行数=...），并作为返回值回给调度侧的执行日志。
任务不对前端暴露任何接口，前端无需感知。

四、测试服实测（2026-09-20）

项	实测
连建车、司机两个维度的关系（团期 `2101174125761265666` / `2027-01-06`）	两次确认均 `code=200`；库内复核两个关系的成员行 `source_id` 同为 `359966520803201024`，被作废的 `359966492122550272` 上无任何在关系中的成员
定时任务 1045	`sys_job` 已注册且 `ACTIVE`，cron `0 10 4 * * ?`；两个 fleet 实例各触发一次均 `code=200`
核对结果与库读数对账	存量处置前 4 → 处置 2 条后 2 → 新建两个关系后仍 2（新关系零悬挂），每一次都与同口径 SQL 读数相同

存量：测试服清查出的历史遗留记录共 4 条，已处置 2 条（改绑到当前在跑的派车记录），另 2 条因对应需求当日已无在途派车记录而保留待人工判断，任务会继续把它们报出来。

五、前端要不要动

不需要。响应结构、字段名、枚举、路径、错误码全部不变。唯一需要知悉的是第二节末尾那句： members[].sourceId 不是稳定标识，不要缓存或用它做跨请求的比对，要稳定标识用 requirementId / orderId。

7.7 KiB 原始文件 Blame 文件历史 Unescape Escape