From 20e19d8693d08ccb47e6533d8523fd44cd546a70 Mon Sep 17 00:00:00 2001 From: yeg <1347747024@qq.com> Date: 星期四, 17 九月 2026 13:12:10 +0800 Subject: [PATCH] fix(merchant): 收款能力自查不再因缺列打成 500 --- .scratch/merchant-capability-visibility/issues/03-manual-capability-verify-with-cooldown.md | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/.scratch/merchant-capability-visibility/issues/03-manual-capability-verify-with-cooldown.md b/.scratch/merchant-capability-visibility/issues/03-manual-capability-verify-with-cooldown.md index 8de7bcb..f7d0367 100644 --- a/.scratch/merchant-capability-visibility/issues/03-manual-capability-verify-with-cooldown.md +++ b/.scratch/merchant-capability-visibility/issues/03-manual-capability-verify-with-cooldown.md @@ -30,4 +30,5 @@ - 2026-09-17 由本会话 grilling 的 D7／D8／Q11 决策立项（见 [spec](../spec.md)）。这是本轮唯一的新增迁移，编号前已确认 `db/migration/` 里最大版本是 147，本次为 `V148`。 - 2026-09-17 代码侧交付。冷却实现取"一个 UPDATE 兼做判定与占位"：`update ... set capability_sync_until = now() + interval 5 minute where id = ? and (capability_sync_until is null or capability_sync_until < now())`，更新到行的那次才去查通道，并发点击直接拿当前快照。5 分钟按仓库既有 5 分钟租约写死在服务里（`MERCHANT_VERIFY_COOLDOWN_MINUTES`），没新开配置项——`stale-hours` 是运维口径，这个只是防连点。`merchantVerify` 刻意**不加** `@Transactional`：冷却窗口必须在通道查询之前落库，且通道查询不能夹在持有该行锁的事务里（这条在类注释里已写死）。未核实的异常路径（`!providerVerificationRequired() || !huifuPaymentProperties.isEnabled()`）直接返回当前快照、不查通道，与 `refreshQuietly` 的守卫一致。测试见 `MerchantPaymentReadinessMerchantViewTests` 的四个冷却用例（含"失败也节流"与"冷却过期后可再查"）。 -- 2026-09-17 复审修复（Spec 6）。原实现里"通道校验关掉/汇付未启用"那条早退分支**不返回 `refreshed`**，而 D9 说手动核实一定带它；客户端把缺失当 `false`，于是在那种配置下也会弹"刚核实过"。现在 `refreshed` 由唯一的返回点统一带上（`boolean refreshed = … && acquireVerifyWindow(...)`，早退已删除），结构上不可能再缺；前端文案也改成如实的"未重新查询通道，显示最近一次结果"。另把冷却的抢窗口逻辑提成 `acquireVerifyWindow`，与读侧的 `capabilityCooldownSeconds` 各管一侧。测试补了 `retryAfterSeconds` 的断言。 +- 2026-09-17 复审修复（Spec 6）。原实现里"通道校验关掉/汇付未启用"那条早退分支**不返回 `refreshed`**，而 D9 说手动核实一定带它；客户端把缺失当 `false`，于是在那种配置下也会弹"刚核实过"。现在 `refreshed` 由唯一的返回点统一带上（`boolean refreshed = … && acquireVerifyWindow(...)`，早退已删除），结构上不可能再缺；前端文案也改成如实的"未重新查询通道，显示最近一次结果"。另把冷却的抢窗口逻辑提成 `acquireVerifyWindow`。测试补了 `retryAfterSeconds` 的断言。 +- 2026-09-17 真机上报 `Unknown column 'capability_sync_until' in 'field list'`（点击「收款能力」即 500）。根因不在判断逻辑：开发库 `talent_card` 的 Flyway 是关的，新列靠启动时 `MerchantOnboardingSchemaInitializer` 补，而那条 `alter table` 没成功（初始化等 DDL 元数据锁的上限是 5 秒，等不到就记 error 放行——这是它在注释里写明的取舍）。已按 V148 同样的 DDL 在开发库手工补列，补完无需重启（列是每次请求现查的）。顺带修掉一处真实脆弱点：`capabilityCooldownSeconds` 原来是本文件里唯一"点名列"的查询，缺列时整条 SQL 报错、把商户页打成 500；现在改成用申请行上已经读到的 `capability_sync_until` 自己算剩余秒数（少一条 select，缺列只是少一个字段 → 按"没有冷却"处理，页面照常显示判定）。时区显式取 `Asia/Shanghai`，与库里 datetime 的解释方式一致。`verifiedAt`／`nextVerifyAt` 的对外字符串格式未变（仍是 `String.valueOf(LocalDateTime)`）。 -- Gitblit v1.7.1