19: 后端执行票 —— 预警/事件族故障根因（部署时序错位，非缺列）

Type: task Status: resolved Assignee: ASUS Label: ready-for-human Category: backend-deployment

根因（已确证，非猜测）

不是缺列需要补，而是部署时序错位：数据库迁移领先于运行中的构建。

事实	证据
运行实例是旧构建	后端进程 PID 37792 启动于 `2026-10-10 08:28:52`，其源码基线为 `d8a6b03`（2026-10-09）
数据库已被上游重构	`927fad2 refactor(warning): 重构预警系统数据结构和业务逻辑`（林仔，2026-10-10 11:43:10 +0800）提交说明明写「移除预警名称和经纬度字段，优化数据库表结构」，该提交从 `EarlyWarning.java` 删除了 `warningName`、`longitude`、`latitude` 映射
旧构建仍读被删列	`d8a6b03` 的 `EarlyWarning` 仍映射 `@TableField("warning_name")` → MyBatis-Plus 生成 `SELECT ... warning_name ... FROM early_warning` → KingbaseES 报「字段 "warning_name" 不存在」
修复已在远端	`927fad2` 与其后的 `94971b5 feat(warning): 添加预警参考服务` 均已包含在 `origin/master`（远端 master 现为 `94971b5`）

sql/early_warning_system.sql 里 early_warning 仍写着 warning_name，那是旧版建表脚本，不能作为当前库结构的依据；warning_name 现在只存在于 warning_type 表（WarningType.java）。

因此本票不需要写新代码

动作是：用 origin/master（≥ 927fad2）重新构建并部署到联调环境。 这是一次部署动作，按仓库规则不自动执行，由维护者执行。

受影响范围（随部署一并验证）

部署后应同时恢复的端点：/equipments/{code}/events/current 与 history、/events/current、/events/history-analysis、/events/handling-efficiency、/events/multidimensional-analysis、/monitoring/situation、/overview/warning-settings、/infrastructure/emergency-support。

部署后必须核对的新事实

927fad2 同时删除了预警的经纬度字段，因此预警类事件将不再有坐标。用户本次提供的真实报警记录本身即 longitude: null, latitude: null。这与「地图对象不上图」是同一族问题：需要确认驾驶舱对无坐标预警事件的呈现（不得伪造坐标），并与前端执行票 24 的坐标纪律一致。

验收

记录新部署实例的启动时间与所依据的提交哈希（必须 ≥ 927fad2，且与 origin/master 一致）。
上述八个端点真实返回业务 code=200，且报警字段真实（warningCode、阈值、报警等级）；确认 warningName 是改由 warning_type 关联取得还是按新契约置空。
重跑 verify/t18-real-audit.mjs，events-* 与 warning-* 相关失败项清零。
若部署后仍有 500，则说明还有第二处结构漂移，需重新取证而非再猜。

关联

发现于票 18；根因为部署时序，与前端执行票 22（前端把 code=500 读成 success）叠加放大了故障表现——两处都要修。

进度

2026-10-12：本票立票（诊断完成，动作＝维护者重新部署）。
2026-10-12 晚间：票 30/31 的现场复验已要求「后端重启」，实例随之更新；本票验收证据于 2026-10-12 深夜补齐（见 Answer）。

Answer

结论：部署时序前提已被消解，验收四条全部满足，本票按证据收口（无需新代码，也无需再部署）。

实例与基线：联调实例 PID 27208（192.168.110.96:8301）启动于 2026-10-12 20:13:30；后端仓库 HEAD = origin/master = d81c977b（工作区干净，git fetch 后一致），927fad2 是 HEAD 的祖先（merge-base --is-ancestor 实测 YES）。票 30/31 的现场复验（票 31 记「后端重启后三端 facilityCount 均 5283」）已把实例带过 927fad2。
受影响端点：带正确入参探测 10 个端点（八端点 + 设备维 events/current、events/history），全部 HTTP 200 + 业务 code=200。报警字段真实：eventName（如「COD监测」）、level=4、thresholdMaxValue=5、坐标与 coordinateValidation.renderable=true 齐全。warningName 已随新契约整体移除（五个含事件族的响应中出现 0 次）——不是置空、也不是独立字段回联，事件名统一由 eventName 携带。
审计复跑：verify/t18-real-audit.mjs 本轮 140/143（此前票 22 时代 33 项失败）。events-* / warning-* 失败清零；余 3 项全部是 monitoring-createdAt（/monitoring/{overview,distribution,situation} 无 createdAt），与基线卡 map-monitoring ③ 行记录的后端缺口完全一致，不属本票范围。
无第二处漂移：审计 141 次只读请求零 5xx。

「部署后必须核对的新事实」的答案：预警事件没有失去坐标。6/6 条预警事件均携带 longitude/latitude 且 coordinateValidation 为 VALID/renderable=true —— 删除的是 early_warning 表自己的经纬度列，契约坐标改由设备回联给出（与报警事件同源）。故「驾驶舱如何呈现无坐标预警事件」这一担忧在当前数据下未触发；前端「无位置不伪造锚点」的既有纪律（票 04/12）仍覆盖将来真无坐标的情形。附带观察（不阻塞本票）：预警事件 location 字段存在脏值（"1"、"43"），属数据侧质量问题，界面显示点位详情时可见。

审计产物：verify/artifacts/t18/live-audit-results.json（本轮 2026-10-12 深夜）；端点探测摘要 verify/artifacts/t19/probe-summary.txt 与逐端点响应体。

19-19-early-warning-warning-name.md 5.7 KB Geschiedenis Ruwe