文件
hl-api-changelog/changelogs-v2/2026-06/24_4369_配房候选数量修复_管理后台.md
T

1.8 KiB
原始文件 Blame 文件历史

配房选酒店候选数量修复(CORE 产品不再被截到 10 家)

变更类型:🔧 修复(后端,前端一般无需改,仅候选数量变多) 端类型:管理后台(房务管家·配房选酒店) 日期:2026-06-24 | 工单:无(每日代码审查批量修复)| PR:#4369 | 服务:hl-order-service-v3(已部署 health UP,网关实测)


背景

每日代码审查发现:配房「选择酒店」候选接口 GET /v3/admin/hotel-candidates 此前对 CORE(核心订单)产品内部被截断到最多 10 家,CUSTOM/团期最多 20 家——使 #4346/#4364「默认不按城市、列全部在售、取前 N」对 CORE 实际只返 10 家,limit 参数(默认 30、上限 50)不生效。

修复(已上线)

候选列表截断改为单一真源:以请求 limit(默认 30、上限 50)为准,不再被内部固定上限(10/20)提前截断。

  • 排序逻辑不变:定制师点名 > 池内 > 普通(isConsultantRecommended / isPoolMatch 标签照常返回)。
  • 现在 CORE 产品也能返回最多 limit(默认 30)家候选,与 CUSTOM/团期口径统一。

前端配合

  • 一般无需改:字段不变,仅候选条数可能变多(CORE 之前最多 10、现在最多 30)。
  • 若前端列表有「只展示前 N」的本地硬编码,可放开到后端 limit 口径(默认 30)。

说明(本 PR 其余为内部加固,无前端影响)

同 PR #4369 还修了一批内部问题(不影响前端契约):车队派单占位并发守卫(防孤儿占用)、配房段预算取最高协议价口径、§13.8 车务回写归属校验、错误码/注释规范等。

验证

  • order-v3 全量 4466/0/0、fleet 全量 1304/0/0(含架构门禁)全绿;两服务部署双实例 health UP,网关实测服务可达。