发现于 #5397(给 loadConfig() 套 .env* overlay)实施过程中的顺带核验;本单只记录,未在该 PR 里改 —— 原因写在下面。
事实
packages/cli/src/commands/doctor.ts:1212(origin/main 98369a8):
} catch {
printWarning('Could not load config for analysis (config checks skipped)');
hasWarnings = true;
}
catch 不带绑定,error 对象当场丢弃。载入失败的真实原因(语法错、import 解析不到、
配置自己抛的业务错、bundle-require 的 esbuild 报错)一个字都不到达终端,--verbose 也没有 ——
这条 warning 是 printWarning 直接打的,不走 HealthCheckResult.fix 那条能被 --verbose
展开的路径,所以没有任何旗标能让操作者看到更多。
后果
#5382 → #5387 → #5397 三单依次把这句话的归因修对了:先是把 posture 的抛错从这个 catch 里
挪出去(#5382),再让 env 派生检查读到 serve 的那份环境(#5387/PR #5398),最后让配置载入也在
serve 的环境下进行(#5397)。三单之后,这句话触发时配置确实坏了 —— os serve 同样载入不了。
但归因对了不等于可行动。操作者现在拿到的是一句「载入不了,检查跳过」,没有任何线索,而
os serve 在同一目录会把真实错误完整打出来。于是 doctor 这条路径的处境从「说错了话」变成
「说的话没有信息量」:诊断命令在它最该出力的一刻(配置坏了),给出的信息严格少于直接跑
os serve。
复现(真机,临时目录):
$ cat objectstack.config.ts
throw new Error('this config is genuinely broken');
$ os doctor
→ Loading configuration for analysis...
⚠ Could not load config for analysis (config checks skipped)
⚠️ Environment is functional but has some warnings.
this config is genuinely broken 不出现在任何地方。
为什么没有顺手改
#5397 的派发口径把判定面限定为「给 loadConfig() 套 overlay」,并明确要求这条 warning
照旧触发、不要过度静默;改写它打印什么属于另一处诊断输出的契约变化(要不要打印 cause、
打印多少、算 warning 还是 error),超出该单被限定的判定面。#5397 的 PR 在这个 catch 上留了
注释说明它现在归因正确,但没有动它的输出。
可能的方向(供分诊,不预设)
与 #4801、cloud#1020 同属「诊断面与运行时不一致」家族的收尾;#5382 / #5387 / #5397 是同一句话
的前三单。
Generated by Claude Code
发现于 #5397(给
loadConfig()套.env*overlay)实施过程中的顺带核验;本单只记录,未在该 PR 里改 —— 原因写在下面。事实
packages/cli/src/commands/doctor.ts:1212(origin/main98369a8):catch不带绑定,error 对象当场丢弃。载入失败的真实原因(语法错、import 解析不到、配置自己抛的业务错、bundle-require 的 esbuild 报错)一个字都不到达终端,
--verbose也没有 ——这条 warning 是
printWarning直接打的,不走HealthCheckResult.fix那条能被--verbose展开的路径,所以没有任何旗标能让操作者看到更多。
后果
#5382 → #5387 → #5397 三单依次把这句话的归因修对了:先是把 posture 的抛错从这个 catch 里
挪出去(#5382),再让 env 派生检查读到 serve 的那份环境(#5387/PR #5398),最后让配置载入也在
serve 的环境下进行(#5397)。三单之后,这句话触发时配置确实坏了 ——
os serve同样载入不了。但归因对了不等于可行动。操作者现在拿到的是一句「载入不了,检查跳过」,没有任何线索,而
os serve在同一目录会把真实错误完整打出来。于是 doctor 这条路径的处境从「说错了话」变成「说的话没有信息量」:诊断命令在它最该出力的一刻(配置坏了),给出的信息严格少于直接跑
os serve。复现(真机,临时目录):
this config is genuinely broken不出现在任何地方。为什么没有顺手改
#5397 的派发口径把判定面限定为「给
loadConfig()套 overlay」,并明确要求这条 warning照旧触发、不要过度静默;改写它打印什么属于另一处诊断输出的契约变化(要不要打印 cause、
打印多少、算 warning 还是 error),超出该单被限定的判定面。#5397 的 PR 在这个 catch 上留了
注释说明它现在归因正确,但没有动它的输出。
可能的方向(供分诊,不预设)
catch (err)+ 按os doctor对非法OS_TENANCY_POSTURE退出码 0 并报告「环境功能正常」—— 抛错被 config 分析的宽 catch 吞成一句「Could not load config」 #5382 既有体例把 cause 挂到fix/--verbose(与 posture finding引回
resolveTenancyPosture()原话同一姿态:引用上游的原始措辞,不改写);HealthCheckResult,与Environment files/Tenancy posture一样走统一的渲染与 verbose 展开,而不是裸printWarning。与 #4801、cloud#1020 同属「诊断面与运行时不一致」家族的收尾;#5382 / #5387 / #5397 是同一句话
的前三单。
Generated by Claude Code