GCP Recommendation AI清除用户事件后查询操作状态仅返回名称、数据未删除

API 探路者

2026-10-22

GCP Recommendation AI 用户事件清除异常排查

遇到的典型异常表现

调用用户事件批量清除接口时，容易碰到两类问题：

权限配置不足
检查调用接口使用的应用默认凭证/服务账号，是否被授予Retail API的管理员操作权限；仅持有只读权限的账号虽然可以正常发起请求拿到操作ID，但清除任务的实际执行流程会被权限拦截，不会回传完整的任务状态。
操作路径拼接错误
核对查询操作状态的接口URL，要和清除请求返回的操作ID完整路径完全匹配，不要手动截取路径片段。少了location层级、catalog层级的话，接口会直接返回仅包含名称的空操作对象，没有核心状态信息。
请求参数格式不规范
核对清除请求的参数：当前接口的事件时间过滤规则要求必须用闭环时间范围做匹配，也就是同时写eventTime > "起始时间"和eventTime < "结束时间"，单写一个起始时间没有结束范围的话，部分场景下接口虽然会返回200状态码和操作ID，但任务会卡在初始化阶段，不会推进执行。另外注意force字段要传布尔值的true，不要传字符串格式的"true"。

重新发起一次清除请求，完整保存请求的初始返回内容，不要只单独记下操作ID字符串：
正常触发任务的初始响应会包含基础元数据，类似结构：
```
{
  "name": "projects/xxx/locations/global/catalogs/default_catalog/operations/xxx",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.retail.v2.PurgeMetadata",
    "createTime": "任务创建时间",
    "operationState": "RUNNING"
  }
}
```
如果发起请求的初始响应本身就只有name字段、没有metadata结构，说明请求在前置校验环节就没真正触发执行流程。
定期查询操作状态时留存完整响应日志：真正进入运行状态的任务，会随着进度推进依次显示RUNNING、SUCCEEDED、FAILED的状态标记，同时会返回累计删除的事件数、失败原因这类核心信息。
如果连续等待24小时状态仍无推进，可以做链路连通性测试：手动写入一条测试用户事件，再发起单条事件删除请求，观察单条操作的状态是否能正常更新。如果单条操作也存在无状态返回的问题，说明当前项目的Retail API底层调度存在异常，需要联系平台技术支持排查项目侧的服务配额与调度配置。

内容的提问来源于stack exchange，提问作者Jacky