mirror of
https://gitee.com/mateos/mateclaw.git
synced 2026-09-13 11:13:43 +08:00
Closes #169 ModelConfigService.validateModel() flagged a duplicate when re-adding a manually-typed (provider, modelName) pair that happened to match a row with deleted=1 in mate_model_config. The user-visible symptom: adding 'dashscope/qwen3-plus' fails with 'model identifier already exists', yet the management page shows no such model. The project itself runs hard-delete via deleteById(), so the user-facing delete path doesn't create deleted=1 rows. The stale rows come from schema migrations (V44, V81) that intentionally tombstone bogus catalog entries — for instance V81 sets deleted=1 on the non-existent 'qwen3-plus' (id=1000000172) so it stays out of routing but preserves the id for audit. ModelConfigEntity has no @TableLogic, and the project has no global logic-delete-field config, so LambdaQueryWrapper queries do not auto-append the deleted filter; the migration tombstones leak into the validate-model query. Add an explicit .eq(getDeleted, 0) to the uniqueness check so migration tombstones don't block legitimate re-adds. Follow-up: several other queries in ModelConfigService share the same oversight (list/get methods), and a future migration could drop the tombstones entirely to align with the V20 hard-delete posture. |
||
|---|---|---|
| .. | ||
| mate | ||