Skip to content

CLI 启动 banner 的 Tenancy: 读布尔 multiTenant,与 ADR-0105 D1 的权威 knob OS_TENANCY_POSTURE 对不上——isolated 会显示成 single-tenant #4801

Description

@xuyushun441-sys

跨分片移交:Part of objectstack-ai/cloud#1020(由 cloud 分片 PM 转入,本条不含那边正在等维护者拍板的许可闸门决策——banner 这半块无论决策怎么落都该修)。

现象

packages/cli/src/utils/format.ts:412-414

if (opts.multiTenant !== undefined) {
  console.log(chalk.dim(`  Tenancy: ${opts.multiTenant ? 'multi-tenant' : 'single-tenant'}`));
}

打印的是布尔 multiTenant(即 OS_MULTI_ORG_ENABLED 那条线),而 ADR-0105 D1 之后权威 knob 是 OS_TENANCY_POSTURE,布尔只是它 unset 时的回退(packages/types/src/env.ts resolveTenancyPosture())。serve 的实际接线读的是 resolveTenancyPosture()

实测证据(来自 cloud#1020 的 boot 日志,真实 CLI 非 mock)

OS_TENANCY_POSTURE=isolated、未设 OS_LICENSE_KEY 启动,一屏之内同时出现:

  Tenancy: single-tenant          ← banner 读布尔
  Plugins: 40 loaded
           …, Organizations, …    ← 企业多组织运行时真的挂上了

banner 说单租户,实际跑的是 isolated + 真墙。

为什么值得修

诊断信息一旦不可信,之后每一次排障都要多绕一圈——cloud#1020 就是靠人工比对插件表才发现 banner 在撒谎的。这不是显示美化,是声明与执行不一致(ADR-0049 那一类)在诊断面的实例。

修法

Tenancy: 改为读 resolveTenancyPosture() 的结果并直接打印 posture 名(single / isolated / group …),而不是把它压扁成一个布尔。调用点需要把 posture 传进 opts(今天传的是 multiTenant 布尔),是否保留布尔字段作为兼容项由实施者判断;若保留,两者不一致时应以 posture 为准。

建议附一条断言 banner 输出与 resolveTenancyPosture() 一致的测试,否则下一个 knob 演进时同样会漂。

关联

  • 来源:objectstack-ai/cloud#1020(EE 许可闸门只钉布尔,OS_TENANCY_POSTURE=isolated 可绕过)
  • ADR-0105 D1(posture 取代布尔)

未指派——记录的 finding,谁开工谁认领。

Metadata

Metadata

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions