HarmonyOS 鸿蒙Next AGC测试版本「审核中数量上限」咨询

HarmonyOS 鸿蒙Next AGC测试版本「审核中数量上限」咨询

提交给华为 AppGallery Connect 官方技术支持 / 工单使用。

一、应用与场景

• 应用类型：HarmonyOS 应用（WebView 容器壳，发邀请测试 / AppTest）
• appId：5765880207854275965
• 发布方式：CI 流水线全自动调用 AGC Publishing / Testing API 发测试版本，鉴权用 Service Account（PS256 JWT 直接当 Bearer）+ API Client（client_credentials 换 access_token）。
• 自动化流程（每次发版按顺序调用）：
  1. GET /publish/v2/upload-url/for-obs 申请 OBS 上传地址
  2. PUT 上传 .app 到 OBS
  3. POST /publish/v2/test/app/version 新建测试版本 → 返回 versionId
  4. POST /publish/v2/test/version/pkg 绑定软件包
  5. PUT /publish/v2/test/app/version 更新测试版本（绑定测试群组）
  6. POST /publish/v2/test/app/version/submit 提交测试版本审核

二、遇到的问题

问题 1（核心阻塞）：提交审核报「审核中数量到达上限」，但找不到这个上限的明文定义

第 6 步「提交测试版本审核」持续失败，HTTP 200，响应体：

{"ret":{"code":204144692,"msg":"[AMIS] submit version for review failed, additional msg is [[AppGalleryConnectAppMetaInfoService]the count of harmony test in audit is up to the limit!]"}}

我们做了以下排查：

• 用 POST /publish/v3/version/brief-info/list 拉了本应用全量版本（请求体 {}，确认无分页、无 totalCount 字段，三种分页参数返回数一致），共 71 条。其中鸿蒙测试版本（releaseType=6）按 state 分布：

  state	我们对照控制台推断的含义	条数
  0	准备提交 / 未完结（已建版本+已绑包，但 submit 没走完）	8
  2	已失效	59
  4	审核中	1
  7	在架 / 测试中	1

• 官方文档《AppTest 邀请测试 - 创建并发布测试版本》写明：「邀请测试最多允许 100 个版本同时在架，邀请测试和公开测试的总计版本数量不超过 100 个。」我们「在架」的版本远不足 100，判断这条 100 的限制不是本次触发原因。

• code 204144692 这条报错不在 Publishing API / Testing API 的任一错误码页中，疑似 AMIS 运行时错误，我们查不到对应的明文上限数字。

• 经验上：每次 CI 失败都会新建一个测试版本（state=0）但未能完成 submit，导致 state=0 的版本逐步累积；累积到 8 个左右后，再 submit 即稳定复现此报错。

问题 2：提交前更新测试版本报 Harmony test apiLevel check failed, package state is abnormal

第 5 步「更新测试版本（绑群组）」会间歇性报：

{"ret":{"code":204144691,"msg":"[AMIS] update version information failed, additional msg is [[AppGalleryConnectAppMetaInfoService]Harmony test apiLevel check failed, package state is abnormal]"}}

我们理解是上传的 .app 在服务端异步解析（apiLevel 校验）尚未完成，目前靠固定间隔重试绕过，但没有可靠的「解析完成」判定依据。

三、希望华为官方解答的问题

1. code 204144692（the count of harmony test in audit is up to the limit）对应的上限具体是多少条？ 这个上限统计的是哪些状态的版本——是只统计「审核中」，还是把「准备提交 / 未完结」（即我们看到的 state=0）也计入？该上限是否有官方文档出处？
2. brief-info/list 返回的 state 数值与控制台版本状态的官方对应关系是什么？ 我们目前只能靠经验推断（0=准备提交、2=已失效、4=审核中、7=在架），希望得到权威对照表。
3. 如何通过 API 正确清理「准备提交 / 未完结」（state=0）的残留测试版本？ 是否有「删除测试版本」或「撤销提交」的开放接口？请提供接口路径、请求参数与鉴权方式。
4. 针对问题 2：上传 .app 后，服务端 apiLevel / 软件包解析需要多久？是否提供查询「软件包解析 / 版本就绪状态」的接口，让我们在解析完成后再调用「更新测试版本 / 提交审核」，而不是盲目重试？
5. 是否有官方推荐的「全自动发测试版本」最佳实践（含失败重试、残留清理、版本就绪轮询），以避免 state=0 版本累积撞上限？

四、可提供的补充材料

• 复现该报错的 CI Job 日志（含 30 次 submit 重试与完整响应体）
• brief-info/list 的完整原始响应（71 条版本明细）
• 各 state=0 残留版本的 versionId 列表

如需以上任一材料，请告知，我们随时提供。