From ab9b1f30b848d1f763fd0012e7ec9e1900f7d019 Mon Sep 17 00:00:00 2001 From: yeg <1347747024@qq.com> Date: 星期四, 17 九月 2026 15:48:18 +0800 Subject: [PATCH] feat(payment): 补齐查询对等物、收口定时开关并接线后台按钮 --- docs/agents/testing.md | 21 +++++++++++++-------- 1 files changed, 13 insertions(+), 8 deletions(-) diff --git a/docs/agents/testing.md b/docs/agents/testing.md index f1a264c..5a8bd0f 100644 --- a/docs/agents/testing.md +++ b/docs/agents/testing.md @@ -75,6 +75,12 @@ - 只补缺失的 DDL（`create table if not exists`、`add column`），**不要**删表重建。手工补 DDL 正是 2026-09-17「点开收款能力就 500 / `Unknown column 'capability_sync_until'`」的解药。 +- **有一条命令可用了**：`.\scripts\apply-sql-file.ps1 -File <某个 .sql> -Yes` 用项目已有的 JDBC 驱动 + 逐条执行 SQL（默认连开发库，可 `-Database/-DatabaseHost/-Port` 覆盖；不带 `-Yes` 只打印不执行）。 + 它认得 `DELIMITER`，所以 `db/migration/V*.sql` 也能原样重放。默认指向**开发库**，别拿它去改测试库 + （测试库由 Flyway 从 `db/migration` 重建，手工 DDL 会让迁移与 history 表对不上）。 + 开发者首次拿到新列：2026-09-17 的 `V149`（支付流水两列）与 `V150`（手输核销码计数表）就是这样落地的， + 对应脚本 `scripts/dev-schema-v149-payment-attempt.sql`（写法可重复执行的那份在迁移里，两者等价）。 - 动结构之前先备份。本机**没有** mysql 客户端、也没有 Docker（README 里指向 `D:\MySQL\...` 和 `docker exec talent-card-mysql-1` 的两条老做法都已失效），要备份就在 DB 主机上做，或照 `scripts/reset-test-db.ps1` 的办法用项目已有的 JDBC 驱动写个单文件程序。 @@ -100,17 +106,16 @@ 新会话不要为了证明它们"是既有的"而重建 worktree：直接看这张表。修好其中任何一项时，请删掉对应行。 -## 环境相关失败（不是基线，别当既有失败放过） +## 环境相关失败：已修（2026-09-17） `PaymentFundConfirmationTests.aPendingConfirmationOfAVerifiedOrderIsRetriedWithoutAnotherVerification` -在测试库累计的「已核销 + 待确认」订单超过 50 条时会**必然**失败：补偿任务扫全库、`order by o.id asc -limit 50`（`PaymentFundConfirmationRetry.retry`），而用例新建的那单 id 最大、排在窗口之外，于是状态停在 -`pending`。这是测试库长期不清理累积出来的，不是代码回归——2026-09-17 实测符合条件的行为 60 条，最早一条 -09-14 就留下了，而且被处理过的行多数停在 `confirming`（仍在扫描条件内），所以不会自己排空。 +原先会随测试库累积而**必然**失败：补偿任务扫全库、`order by o.id asc limit 50`，用例新建的那单 id 最大、 +排在窗口之外。 -现象、证据与建议改法见 -[.scratch/payment-fund-confirmation-retry/issues/01](../../.scratch/payment-fund-confirmation-retry/issues/01-retry-limit-blocked-by-accumulated-leftovers.md) -（属支付链路范围，本轮只排查未修）。要么让用例自己把窗口腾出来，要么清理测试库遗留（后者只能缓解）。 +2026-09-17 已按本文件的建议修好——该用例先把**自己之外**的相关行移出扫描条件，于是它从「环境相关失败」 +变成稳定通过；同一天还把同一处扫描改为「每单只看最新一笔成功支付」，并把它扩展到 `reverting`（撤销核销 +的回退在途）状态。以后新写这类「后台任务只处理了我这条」的用例，照它的做法先腾窗口，不要再依赖测试库的 +累积状况。 ## 测试库的状态是共享的 -- Gitblit v1.7.1