Google Cloud在2026年8月22日的发布说明中确认，Apigee控制台保存开发者自定义属性时可能出现假成功的问题已经修复。此前用户修改属性后，界面看起来已经保存，但重新加载页面时，新值有时会恢复成旧内容。
该故障对应编号540008387，范围限定在Apigee管理界面。官方说明通过Apigee API更新开发者属性不受影响，因此自动化系统与控制台操作在故障期间可能呈现不同结果。
开发者属性曾出现保存后回滚
这一缺陷最容易误导操作人员的地方，是保存动作表面上能够完成。若管理员没有刷新页面复查，就可能按照新属性已经生效的前提继续配置API产品、门户或后续业务流程。
重新加载后恢复旧值，说明实际后端状态与界面即时显示不一致。对于依赖属性执行访问控制、用户分组或外部系统同步的环境，这种差异会增加定位难度。
修复上线后，控制台应能正确持久化修改。已经在故障期间做过批量编辑的团队仍需抽查，因为平台修复不会自动重放此前没有真正写入的值。
自定义属性用于保存开发者键值信息
Apigee的开发者记录除了邮箱、姓名和状态，还可以添加自定义键值属性。团队常用这些字段保存客户层级、内部标识、渠道来源或与门户和业务系统关联的信息。
官方文档说明，每个开发者最多可以设置18个自定义属性。属性数量有限，命名和用途应提前统一，避免同一业务含义被多个相近字段重复表示。
自定义属性本身只是数据字段，是否参与授权或流量控制取决于外围逻辑。若策略、门户或同步任务依据这些值做决定，应把允许值、缺省行为和异常处理写入配置规范。
假成功会扩大配置与审计风险
当界面显示新值而后端仍保留旧值时，人工截图或操作记录可能与实际系统状态冲突。故障排查人员看到的是旧配置，操作者却确信自己已完成修改，双方很容易把问题误判为缓存或策略延迟。
涉及客户等级、外部账号标识或内部流程状态时，错误属性还可能让下游同步产生不一致。即使属性不直接用于安全决策，也会影响报表、门户展示和客户支持判断。
重要配置的完成标准不应只是出现保存成功提示。更可靠的流程是保存后重新加载，再通过API或下游系统确认最终值与变更单一致。
控制台编辑与API更新需要区别对待
发布说明指出，Apigee API在此次界面故障期间不受影响。需要批量修改或要求可重复执行的团队，可以继续通过REST接口管理开发者属性，并保存请求结果作为审计依据。
不过，完整更新开发者记录时要特别谨慎。部分更新方法会用提交内容替换现有详情，遗漏的字段可能被删除，因此自动化脚本应先读取当前记录、合并目标变更，再提交完整且经过校验的数据。
官方API还提供针对开发者属性的新增和更新方法。选择细粒度属性接口可以减少覆盖其他字段的风险，但仍应检查响应、重读资源，并确保脚本使用稳定的开发者标识。
缓存与并发写入仍可能造成短暂差异
Apigee文档提示，开发者自定义属性可能至少缓存180秒。保存后立即由代理流读取时，短时间看到旧值不一定代表保存失败，应区分缓存传播与此次已经修复的控制台持久化问题。
同一开发者记录还应避免并发更新。多个控制台会话、门户同步任务和自动化脚本在接近同一时间写入，可能互相覆盖，即使每一次请求单独看都成功。
更稳妥的做法是顺序执行修改，保存后重新读取，再等待缓存窗口并验证实际代理行为。使用Drupal门户或其他外部开发者门户时，还要检查同步方向和更新时间，防止门户中的旧记录再次覆盖Apigee中的新属性。
