-- 编号让位（2026-09-17）：本文件原为 V151，同批让号后顺延为 V154（远端那两个提交占了 V148–V150）。
|
-- 「取消意图」要能跨请求活到关单结论回来的那一刻。
|
--
|
-- 用户在通道说「关单处理中」时点了取消，服务端当次只能回一句「取消处理中」——真正该取消的时机是
|
-- 几分钟后关单有了结论。旧实现没有把这次意图落库，于是关单真的关掉之后没有任何人去收那笔订单：
|
-- 用户点的取消丢了，订单还是「待支付」，页面上看着就是「点了取消还是卡住」，只能再点一次取消，
|
-- 或者等到订单 15 分钟过期被清理收掉。
|
--
|
-- cancel_requested_at 记的是「这次取消请求被受理的时间」，由对账在「每笔尝试都有结论」之后落地
|
-- （见 PaymentReconciliationService.cancelOrdersAwaitingCloseConclusion）。
|
--
|
-- 与 V149 同样的理由，这一列必须同样落到开发库：开发库（局域网共享的 talent_card）Flyway 关闭、
|
-- 结构不由迁移维护，只写迁移会让开发库缺列，取消接口直接以 Unknown column 500。
|
-- 等价的纯 DDL 在 scripts/dev-schema-v151-order-cancel-request.sql。
|
DROP PROCEDURE IF EXISTS add_order_cancel_request_column;
|
DELIMITER //
|
CREATE PROCEDURE add_order_cancel_request_column()
|
BEGIN
|
IF NOT EXISTS (SELECT 1 FROM information_schema.columns
|
WHERE table_schema = DATABASE() AND table_name = 'benefit_order'
|
AND column_name = 'cancel_requested_at') THEN
|
ALTER TABLE benefit_order
|
ADD COLUMN cancel_requested_at DATETIME DEFAULT NULL COMMENT '人才端点过取消、等关单结论的时间';
|
END IF;
|
END //
|
DELIMITER ;
|
CALL add_order_cancel_request_column();
|
DROP PROCEDURE add_order_cancel_request_column;
|
