OPC/goauto
2
0
Fork 0
Code Issues 192 Pull Requests Actions Packages Projects Releases Wiki Activity

Admin 重启失败：#135 迁移错误引用 MySQL 8.4 CHECK_CONSTRAINTS.TABLE_NAME #140

New Issue
Closed
opened 2026-08-29 08:41:30 +08:00 by ila · 3 comments
ila commented 2026-08-29 08:41:30 +08:00
Owner
Copy Link
Copy Source

所属与来源

  • 关联工单：#135（引入缺陷）、#139（修复后重启 Admin 时发现，与 #139 实现无因果关系）。
  • 来源：用户于 2026-08-29 反馈“Admin 重启失败”，经本机启动日志与 MySQL 8.4 只读检查定位。
  • 类型：Server / MySQL 迁移兼容性缺陷。
  • 设计证据：无页面、组件或交互变化，恢复既有启动行为，不需要原型。

当前事实与根因

本机配置校验正常：MySQL 127.0.0.1:3307/goauto，Server 8010，Web 9527。两个端口均无监听。

server/temp/startup-migration.log 显示服务端在启动迁移阶段失败：

Error 1054 (42S22): Unknown column 'table_name' in 'where clause'
SELECT COUNT(*) FROM information_schema.check_constraints
WHERE constraint_schema = DATABASE()
  AND table_name = 'purchase_task'
  AND constraint_name = 'ck_purchase_task_spec_source'

MySQL 8.4 的 information_schema.CHECK_CONSTRAINTS 只有 CONSTRAINT_CATALOG、CONSTRAINT_SCHEMA、CONSTRAINT_NAME、CHECK_CLAUSE，没有 TABLE_NAME。表归属需要通过 TABLE_CONSTRAINTS 获取。

缺陷由 #135 提交 679f469 的 ensureMySQLDirectSelectConstraint 引入。SQLite 测试会因非 MySQL 方言直接跳过该分支，现有全量验证也没有实际连接 MySQL 8.4 执行启动迁移，因此未发现。

当前本机数据库为可恢复的部分迁移状态：

  • purchase_task.task_type 已存在，默认值 syb_order，非空；
  • 本次回填影响 0 行；
  • 原 ck_purchase_task_spec_source 仍存在，未被删除；
  • 原约束尚不包含 direct_select；
  • 失败发生在约束变更前，未发现数据删除或约束丢失。

目标

  1. 兼容 MySQL 8.4 查询检查约束，恢复服务端启动迁移。
  2. 将 ck_purchase_task_spec_source 安全扩展为包含 direct_select。
  3. 重启后 Server 8010 与 Web 9527 正常可用。
  4. 补充测试，避免再使用 CHECK_CONSTRAINTS.TABLE_NAME。

非目标

  • 不改变 #135 的业务语义、任务状态或 API。
  • 不新增数据库表、字段或索引。
  • 不修改其他迁移。
  • 不清理、重置或重建现有数据库。
  • 不修改 Admin 页面。

实施方案

  1. 将约束存在性查询改为基于 information_schema.TABLE_CONSTRAINTS。
  2. 查询 CHECK_CLAUSE 时，以 schema、constraint name 联接 TABLE_CONSTRAINTS 和 CHECK_CONSTRAINTS，并限定 purchase_task 与 CHECK 类型。
  3. 保持幂等：
    • 已包含 direct_select 时不修改；
    • 存在旧约束时先删除再按完整允许值重建；
    • 不存在时直接创建。
  4. 抽出可测试的 SQL 常量或查询构造，新增 MySQL 8.4 元数据契约测试。
  5. 代码验证通过后，等待用户明确授权，再在本机数据库执行迁移并重启 Admin。

数据库与安全门禁

  • 本工单修复的是既有 #135 迁移，但真实执行会删除并重建检查约束，仍属于数据库迁移高风险操作。
  • 实施代码和不连接真实数据库的测试可先完成。
  • 在本机执行迁移/重启前必须再次获得用户明确授权。
  • 不输出数据库密码，不修改业务数据，不执行删除表、清库或重建数据库。

验收标准

  • SQL 不再引用不存在的 CHECK_CONSTRAINTS.TABLE_NAME。
  • MySQL 8.4 上迁移成功且可重复执行。
  • ck_purchase_task_spec_source 包含 direct_select。
  • Server 8010 健康检查返回 200。
  • Web 9527 可访问，Admin 可登录/打开。
  • 相关 Go 测试、Server 构建和仓库严格检查通过。
  • 未改动业务数据、接口、页面或其他迁移。

验证方式

  • 定向 Go 单测覆盖查询结构、旧约束升级和已升级幂等分支。
  • go test ./app/goauto/migrations/... ./cmd/migrate/migration/version-local/...
  • go build ./...
  • python dev_scripts/harness.py check --strict
  • 授权后：执行本机启动迁移，在线查询约束表达式，验证 /api/v1/health 与 Web 页面。

文档影响

无长期文档影响：仅修复 MySQL 8.4 元数据查询兼容性，不改变配置、数据结构、接口、业务规则或运维命令；完成后跳过 Wiki 更新与同步。

状态

实现、自动化验证、本机数据库迁移及 Admin 重启验证均已完成，待用户验收。

## 所属与来源 - 关联工单：#135（引入缺陷）、#139（修复后重启 Admin 时发现，与 #139 实现无因果关系）。 - 来源：用户于 2026-08-29 反馈“Admin 重启失败”，经本机启动日志与 MySQL 8.4 只读检查定位。 - 类型：Server / MySQL 迁移兼容性缺陷。 - 设计证据：无页面、组件或交互变化，恢复既有启动行为，不需要原型。 ## 当前事实与根因 本机配置校验正常：MySQL `127.0.0.1:3307/goauto`，Server 8010，Web 9527。两个端口均无监听。 `server/temp/startup-migration.log` 显示服务端在启动迁移阶段失败： ```text Error 1054 (42S22): Unknown column 'table_name' in 'where clause' SELECT COUNT(*) FROM information_schema.check_constraints WHERE constraint_schema = DATABASE() AND table_name = 'purchase_task' AND constraint_name = 'ck_purchase_task_spec_source' ``` MySQL 8.4 的 `information_schema.CHECK_CONSTRAINTS` 只有 `CONSTRAINT_CATALOG`、`CONSTRAINT_SCHEMA`、`CONSTRAINT_NAME`、`CHECK_CLAUSE`，没有 `TABLE_NAME`。表归属需要通过 `TABLE_CONSTRAINTS` 获取。 缺陷由 #135 提交 `679f469` 的 `ensureMySQLDirectSelectConstraint` 引入。SQLite 测试会因非 MySQL 方言直接跳过该分支，现有全量验证也没有实际连接 MySQL 8.4 执行启动迁移，因此未发现。 当前本机数据库为可恢复的部分迁移状态： - `purchase_task.task_type` 已存在，默认值 `syb_order`，非空； - 本次回填影响 0 行； - 原 `ck_purchase_task_spec_source` 仍存在，未被删除； - 原约束尚不包含 `direct_select`； - 失败发生在约束变更前，未发现数据删除或约束丢失。 ## 目标 1. 兼容 MySQL 8.4 查询检查约束，恢复服务端启动迁移。 2. 将 `ck_purchase_task_spec_source` 安全扩展为包含 `direct_select`。 3. 重启后 Server 8010 与 Web 9527 正常可用。 4. 补充测试，避免再使用 `CHECK_CONSTRAINTS.TABLE_NAME`。 ## 非目标 - 不改变 #135 的业务语义、任务状态或 API。 - 不新增数据库表、字段或索引。 - 不修改其他迁移。 - 不清理、重置或重建现有数据库。 - 不修改 Admin 页面。 ## 实施方案 1. 将约束存在性查询改为基于 `information_schema.TABLE_CONSTRAINTS`。 2. 查询 `CHECK_CLAUSE` 时，以 schema、constraint name 联接 `TABLE_CONSTRAINTS` 和 `CHECK_CONSTRAINTS`，并限定 `purchase_task` 与 CHECK 类型。 3. 保持幂等： - 已包含 `direct_select` 时不修改； - 存在旧约束时先删除再按完整允许值重建； - 不存在时直接创建。 4. 抽出可测试的 SQL 常量或查询构造，新增 MySQL 8.4 元数据契约测试。 5. 代码验证通过后，等待用户明确授权，再在本机数据库执行迁移并重启 Admin。 ## 数据库与安全门禁 - 本工单修复的是既有 #135 迁移，但真实执行会删除并重建检查约束，仍属于数据库迁移高风险操作。 - 实施代码和不连接真实数据库的测试可先完成。 - 在本机执行迁移/重启前必须再次获得用户明确授权。 - 不输出数据库密码，不修改业务数据，不执行删除表、清库或重建数据库。 ## 验收标准 - [ ] SQL 不再引用不存在的 `CHECK_CONSTRAINTS.TABLE_NAME`。 - [ ] MySQL 8.4 上迁移成功且可重复执行。 - [ ] `ck_purchase_task_spec_source` 包含 `direct_select`。 - [ ] Server 8010 健康检查返回 200。 - [ ] Web 9527 可访问，Admin 可登录/打开。 - [ ] 相关 Go 测试、Server 构建和仓库严格检查通过。 - [ ] 未改动业务数据、接口、页面或其他迁移。 ## 验证方式 - 定向 Go 单测覆盖查询结构、旧约束升级和已升级幂等分支。 - `go test ./app/goauto/migrations/... ./cmd/migrate/migration/version-local/...` - `go build ./...` - `python dev_scripts/harness.py check --strict` - 授权后：执行本机启动迁移，在线查询约束表达式，验证 `/api/v1/health` 与 Web 页面。 ## 文档影响 无长期文档影响：仅修复 MySQL 8.4 元数据查询兼容性，不改变配置、数据结构、接口、业务规则或运维命令；完成后跳过 Wiki 更新与同步。 ## 状态 实现、自动化验证、本机数据库迁移及 Admin 重启验证均已完成，待用户验收。
ila commented 2026-08-29 08:47:29 +08:00
Author
Owner
Copy Link
Copy Source

实现已推送，等待数据库执行授权

提交：a6cc1c6 fix(migrations): support MySQL 8.4 checks (#140)。

  • 约束查询改为 TABLE_CONSTRAINTS 联接 CHECK_CONSTRAINTS，不再引用 MySQL 8.4 不存在的 CHECK_CONSTRAINTS.TABLE_NAME。
  • 新查询已在本机 MySQL 8.4 只读执行成功。
  • 新增回归测试覆盖元数据查询结构、旧约束、已升级约束及 MySQL 字符集前缀。
  • 定向测试、Server 全量测试/构建、DevHarness 严格检查和全组件验证全部通过。

实施期间 2026-08-29 08:43:33 出现一次外部/手工启动尝试，使用工作区新源码成功通过了本缺陷点；当前只读核验确认 ck_purchase_task_spec_source 已包含 direct_select，且迁移版本 1787885300000 已记录。该启动随后被独立缺陷 #141 阻断，Server/Web 仍未启动。

无长期文档影响，跳过 Wiki 更新与同步。工单保持打开，待 #141 修复获授权执行并完成 Admin 联合重启验证。

## 实现已推送，等待数据库执行授权 提交：`a6cc1c6 fix(migrations): support MySQL 8.4 checks (#140)`。 - 约束查询改为 `TABLE_CONSTRAINTS` 联接 `CHECK_CONSTRAINTS`，不再引用 MySQL 8.4 不存在的 `CHECK_CONSTRAINTS.TABLE_NAME`。 - 新查询已在本机 MySQL 8.4 只读执行成功。 - 新增回归测试覆盖元数据查询结构、旧约束、已升级约束及 MySQL 字符集前缀。 - 定向测试、Server 全量测试/构建、DevHarness 严格检查和全组件验证全部通过。 实施期间 2026-08-29 08:43:33 出现一次外部/手工启动尝试，使用工作区新源码成功通过了本缺陷点；当前只读核验确认 `ck_purchase_task_spec_source` 已包含 `direct_select`，且迁移版本 `1787885300000` 已记录。该启动随后被独立缺陷 #141 阻断，Server/Web 仍未启动。 无长期文档影响，跳过 Wiki 更新与同步。工单保持打开，待 #141 修复获授权执行并完成 Admin 联合重启验证。
ila commented 2026-08-29 08:52:04 +08:00
Author
Owner
Copy Link
Copy Source

本机迁移与 Admin 重启验证完成，待验收

用户于 2026-08-29 明确授权 #140、#141 执行本机数据库迁移、权限写入并重启 Admin。

  • #140 提交：a6cc1c6。
  • 本机 MySQL 8.4 启动迁移成功，不再出现 CHECK_CONSTRAINTS.TABLE_NAME 错误。
  • 1787885300000 已记录；ck_purchase_task_spec_source 在线查询确认包含 direct_select。
  • Server 8010 的 /api/v1/health 返回 HTTP 200。
  • Web 9527 返回 HTTP 200。
  • Chrome 可视检查进入 /#/dashboard，页面标题“工作台 - 自动采集采购后台”，控制台无错误。
  • 全组件验证在迁移前已通过；无长期文档影响，未更新 Wiki。

工单进入待验收。

## 本机迁移与 Admin 重启验证完成，待验收 用户于 2026-08-29 明确授权 #140、#141 执行本机数据库迁移、权限写入并重启 Admin。 - #140 提交：`a6cc1c6`。 - 本机 MySQL 8.4 启动迁移成功，不再出现 `CHECK_CONSTRAINTS.TABLE_NAME` 错误。 - `1787885300000` 已记录；`ck_purchase_task_spec_source` 在线查询确认包含 `direct_select`。 - Server 8010 的 `/api/v1/health` 返回 HTTP 200。 - Web 9527 返回 HTTP 200。 - Chrome 可视检查进入 `/#/dashboard`，页面标题“工作台 - 自动采集采购后台”，控制台无错误。 - 全组件验证在迁移前已通过；无长期文档影响，未更新 Wiki。 工单进入待验收。
ila commented 2026-08-29 20:44:01 +08:00
Author
Owner
Copy Link
Copy Source

用户于 2026-08-29 明确确认本工单通过验收。验收结论已记录，现关闭工单。没有新的长期事实变化，本次不重复同步 Wiki。

用户于 2026-08-29 明确确认本工单通过验收。验收结论已记录，现关闭工单。没有新的长期事实变化，本次不重复同步 Wiki。
ila closed this issue 2026-08-29 20:44:02 +08:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin ila
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: OPC/goauto#140