Skip to content

client: environments.delete still documents a one-call cascade delete and has no purge option — once the hosted cloud enforces ADR-0014's two-step delete, SDK users can archive but never purge #17636

Description

@hotlong

现象

packages/client/src/index.tsorigin/main)的 environments.delete

/**
 * Cascade-delete an environment: cleans up credential/member/package_installation
 * rows, releases the physical database via the provisioning adapter, and
 * removes the `sys_environment` row. Default environments require `force: true`.
 */
delete: async (id: string, opts?: { force?: boolean }) => {
  const qs = opts?.force ? '?force=1' : '';

为什么现在要改

托管云的 DELETE /api/v1/cloud/environments/:id 正在改为遵守 ADR-0014 的两步删除(objectstack-ai/cloud#2187,PR objectstack-ai/cloud#2188):

  • 活跃环境 → 归档(响应 archived: true,保留期内可恢复)
  • 已归档环境 + ?purge=1 → 才真正拆除
  • ?force=1 只是「确认这是生产环境」,永远不等于 purge
  • DELETE /cloud/organizations/:id 在组织名下仍有任何环境时返回 409

该 PR 合并后,这个客户端方法会出现三处与线上不一致:

  1. JSDoc 说谎:写的是「级联删除、释放物理库、删除行」,实际对活跃环境只归档
  2. purge 选项SDK 用户完全无法 purgeopts 只有 force,而服务端明确拒绝把 force 当 purge(重试一次 ?force=1 就毁掉环境,正是两步删除要防的事故)
  3. 返回类型不完整:缺 archivedpurgeDeferredretentionDays

验收

  1. opts 增加 purge?: boolean?purge=1forcepurge 可同时传(生产环境拆除需要两者)
  2. JSDoc 按两步语义重写:活跃环境归档、purge 仅对已归档环境生效、force 是生产确认而非 purge
  3. 返回类型声明 archivedpurgeDeferredretentionDays(以服务端实际响应为准,勿凭文档臆造字段——见同文件注释里记录过的 credential 教训)
  4. 若客户端文档站有该方法的页面,同步更新

顺序

等 objectstack-ai/cloud#2188 合并后再开工,以服务端实际响应形状为准。

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions