大白话
sidecar 因 token 轮换 respawn 之后,composer 的模型预检认为**「本次引擎启动没有加载这个模型」**,
平台模型与 BYOK 都被拦,而同一时刻引擎的 /config/providers 列得出 10 个模型。
直到 renderer 重载才恢复。
证据强度:相关性,不是隔离出的因果
#783 打包真机 L2 期间观察到。已排除一个候选:不是 #784 的 refreshEngine() 接线问题
—— reload 之后跑完一次完整安装(必走 refreshEngine)再发,仍然成功。
但没有隔离出真因,所以这张票的第一步是勘破而不是修。
与 REQ-128 无关
本轮顺带发现,不属于 Phase 3 范围。建议按 REQ-109/110 的 token 轮换面查。
建议的勘破问题
- composer 的模型预检读的是什么?它的数据源与
/config/providers 是不是同一份?
- sidecar respawn 时,那份数据由谁负责刷新?有没有人负责?
- renderer reload 之所以能恢复,是因为重新取了一次还是因为别的副作用?
- 这个状态用户可观察的表现是什么(是报错、是灰掉、还是静默失败)?
判据
修之前先稳定复现。复现不出来就如实写「未能复现」,不要凭一次观察改代码 ——
本仓已有「凭相关性改代码」的教训。
出处
#783 打包真机 L2(PR #794)§8「本轮顺带发现、不属于 REQ-128 的一条」。
大白话
sidecar 因 token 轮换 respawn 之后,composer 的模型预检认为**「本次引擎启动没有加载这个模型」**,
平台模型与 BYOK 都被拦,而同一时刻引擎的
/config/providers列得出 10 个模型。直到 renderer 重载才恢复。
证据强度:相关性,不是隔离出的因果
#783打包真机 L2 期间观察到。已排除一个候选:不是#784的refreshEngine()接线问题—— reload 之后跑完一次完整安装(必走
refreshEngine)再发,仍然成功。但没有隔离出真因,所以这张票的第一步是勘破而不是修。
与 REQ-128 无关
本轮顺带发现,不属于 Phase 3 范围。建议按 REQ-109/110 的 token 轮换面查。
建议的勘破问题
/config/providers是不是同一份?判据
修之前先稳定复现。复现不出来就如实写「未能复现」,不要凭一次观察改代码 ——
本仓已有「凭相关性改代码」的教训。
出处
#783打包真机 L2(PR #794)§8「本轮顺带发现、不属于 REQ-128 的一条」。