matrixorigin / matrixorigin/matrixone
[Bug][Compatibility]: information_schema FK metadata mismatch breaks GORM AutoMigrate
- Dominant language
- Go
- Stars
- 1.9k
- Forks
- 311
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 768
Description
## Description
The Gin-Vue Admin application cannot complete GORM `AutoMigrate` against MatrixOne. Its migration checks `information_schema.table_constraints` and then attempts to add a foreign key that MatrixOne already considers present. MatrixOne returns a duplicate-constraint error, so the application terminates during startup.
## Environment
- MatrixOne cloud endpoint exposed through the MySQL protocol on port 6001
- Application: Gin-Vue Admin (`integration-gin-vue-admin-web`)
- Observed: 2026-09-16 (private `mo-scenario` cluster)
## Actual behavior
The application emits the following sequence:
```sql
SELECT count(*)
FROM INFORMATION_SCHEMA.table_constraints
WHERE constraint_schema = 'gin_vue_admin_mo'
AND table_name = 'user_roles'
AND constraint_name = 'fk_user_roles_user';
ALTER TABLE `user_roles`
ADD CONSTRAINT `fk_user_roles_user`
FOREIGN KEY (`user_id`) REFERENCES `users`(`id`);
```
The ALTER fails with:
```text
Error 1061 (42000): Duplicate foreign key constraint name 'fk_user_roles_user'
```
The application logs `自动迁移失败` and exits; the server container repeatedly restarts and the health endpoint is unavailable. The metadata check and the DDL result are inconsistent from the migration tool's point of view.
## Minimal reproduction shape
```sql
CREATE DATABASE gin_vue_fk_repro;
USE gin_vue_fk_repro;
CREATE TABLE users (id BIGINT PRIMARY KEY);
CREATE TABLE user_roles (user_id BIGINT);
ALTER TABLE user_roles
ADD CONSTRAINT fk_user_roles_user
FOREIGN KEY (user_id) REFERENCES users(id);
```
Run the equivalent GORM `AutoMigrate` a second time. The second run should discover the existing constraint through `information_schema` and complete without issuing a duplicate `ALTER TABLE`; on MatrixOne it receives 1061 instead.
## Expected behavior
`information_schema.table_constraints` should expose the existing foreign key in the MySQL-compatible shape expected by migration tools, and repeated `AutoMigrate` should be idempotent. If a duplicate constraint is attempted, MatrixOne should provide behavior compatible with MySQL metadata/DDL semantics so the application can make the correct decision.
## Impact
A supported MySQL ORM cannot start against an existing MatrixOne schema without a MatrixOne-specific migration workaround.
## Related
- #25103 (information_schema compatibility gaps affecting migration tooling)
- #26858 (foreign-key replacement under the same name)
- #27654 (constraint/index metadata inconsistencies)
Contributor guide
Assessment
This issue has not been assessed yet.