Misskey项目中pages/update接口的命名冲突问题分析

问题现象

在Misskey项目中，当开发者使用pages/update接口更新页面内容时，如果仅提供pageId和content参数，系统会返回"Specified name already exists"错误。这是一个典型的API接口行为异常问题，影响了开发者对页面内容的正常更新操作。

技术背景

Misskey是一个开源的分布式社交网络平台，其页面系统允许用户创建和编辑自定义页面。pages/update接口设计用于更新已存在的页面内容，理论上应该支持部分字段更新。

问题详细分析

当开发者发送如下JSON请求时会出现问题：

{
  "pageId": "目标页面ID",
  "content": [页面内容数组]
}

系统会返回错误响应：

{
  "error": {
    "message": "Specified name already exists.",
    "code": "NAME_ALREADY_EXISTS"
  }
}

经过测试发现，如果在请求中添加一个随机的name参数，则操作可以正常完成：

{
  "pageId": "目标页面ID",
  "name": "随机名称",
  "content": [页面内容数组]
}

问题根源

这个问题与之前报告过的#14747号问题类似，表明系统中存在一个已知的命名验证逻辑缺陷。具体表现为：

1. 当不提供name参数时，系统可能默认尝试使用空字符串或null作为name值进行验证
2. 验证逻辑错误地将这种情况视为名称冲突
3. 该问题在第二个创建的页面上才会出现，说明可能与数据库中的默认值设置有关

解决方案建议

针对这个问题，建议从以下几个方面进行修复：

1. 参数验证逻辑优化：更新接口应该明确区分创建和更新操作的参数要求
2. 默认值处理：当name参数缺失时，应保留原有名称而非尝试设置空值
3. 错误处理改进：提供更明确的错误信息，帮助开发者理解问题所在

临时解决方案

在官方修复发布前，开发者可以采用以下临时解决方案：

1. 在更新请求中始终包含name参数，即使不需要修改名称
2. 可以先使用pages/show接口获取当前页面信息，然后在更新时包含所有必要字段

总结

这个Bug影响了Misskey页面系统的正常使用，特别是在自动化更新场景下。虽然通过添加随机name参数可以临时解决，但长期来看需要在系统层面修复参数验证逻辑。对于开发者而言，理解这个问题的表现和临时解决方案可以避免开发过程中的困扰。