文件
hl-api-changelog/changelogs-v2/2026-09/07_7263_大期数团期产品库存字段静默降级修复-修复-管理后台.md
T
jw和Claude Opus 4.8 699fc4c04e
changelog-filename-gate / validate (push) Successful in 2s
docs(changelog): #7263 大期数团期产品库存字段静默降级修复(修复,前端无需改动)
分片下沉 product-v2 GroupBatchStockHelper,≥约260期 GROUP 产品的库存/已报名/
有效订单数/展示态由静默错值恢复准确;无接口/字段/路径/参数/枚举/错误码变化。
后端 PR #7268 squash f1eb72444 合入 dev-v3,测试服 313 期 AC-1~AC-13 实测通过。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T5raGi2iBzrbDwiENbpWY2
2026-09-07 15:13:58 +08:00

3.9 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 7263 大期数团期产品(存活班期 ≥ 约 260 期)库存/已报名/有效订单数/展示态由静默错值恢复为准确值(无接口、字段、路径、参数变化) multiple jw(GIT) 修复 deployed verified not_required 纯后端修复,前端无需改动:不新增/不修改任何接口,响应字段、路径、参数、枚举、错误码全部不变,仅让大期数 GROUP 产品的库存类计算字段由错变对。分片下沉到 product-v2 的 GroupBatchStockHelper 内部(PR #7268 已合入 dev-v3,squash f1eb72444)。测试服 313 期全链路 AC-1~AC-13 实测通过(含改前静默降级复现、改后 4 分片调用日志 100/100/100/13、真实线上订单聚合、造数清理回落基线)。 2026-09-07 dev-v3

大期数团期产品库存字段静默降级修复(修复)

一、给前端的一句话

前端无需任何改动。 本次修复不动接口、不动字段、不动路径、不动参数、不动枚举、不动错误码,只是让存活班期数很多(约 260 期以上)的 GROUP 团期产品,其库存类字段从「悄悄算错」恢复为「算对」。字段还是原来那些字段,结构一模一样,只是数值变准了。

二、症状(改前)

product-v2 聚合 order-v3 活跃订单数时,把该产品全部班期 ID 一次性拼进一个 GET 请求的 query string。当存活班期 ≥ 约 260 期时,请求行超过 order-v3 内嵌 Tomcat 默认 max-http-header-size(8192 字节),order-v3 在协议层直接拒收,product-v2 侧把它当成「无活跃订单」降级——接口仍返回 HTTP 200,但下面这些字段悄悄退化为只含线下占位值:

  • 管理端班期列表 / 统一价格日历:orderCount、enrolledPeople、remainStock、remainParticipants、sold、bookedRooms、sellable、batchStatus
  • 小程序班期列表 / 价格日历 / 最早可售日 / 产品详情:enrolledCount、remainFamilies、remainParticipants、batchStatus、isSelectable、remainStock、isBooking
  • order-v3 团期看板经 internal 详情合并的库存类字段

后果:满员班期可能显示为「可选 / 可订」,运营选完才被创单侧拒、用户点进去才发现无名额;小程序侧还会把错值缓存 5 分钟。

三、修复(改后)

聚合改为在 product-v2 内部按每片 ≤100 个班期 ID 分片串行调用 order-v3、内存合并,任意期数都不再超限。响应契约完全不变,只是数值恢复准确。

四、受影响接口(全部「复用不改」,仅数值由错变对)

端 接口
管理后台 GET /admin/product/item/:id/schedule/list
管理后台 GET /admin/product/item/:id/pricing-calendar
管理后台 GET /admin/product/item/order-picker
小程序端 GET /mp/product/:id/schedules
小程序端 GET /mp/product/:id/price-calendar
小程序端 GET /mp/product/:id/earliest-available-date
小程序端 GET /mp/product/:id (isBooking)

以上接口的 method、path、入参、出参字段、枚举、错误码均无变化,前端调用方式、类型定义、渲染逻辑一律不用改。

五、影响范围

  • 只影响存活班期数很多(约 260 期以上)的 GROUP 产品;期数较少的产品改前改后表现一致。
  • 二期尚未上生产,本修复当前只作用于测试环境及二期上线后随班期累积而到来的将来。
  • 后端只滚 hl-product-service-v2,order-v3 / 网关 / 其它服务不动。

关联 / 联系人