runtime(standalone-stack): `detectDriverFromUrl()` 对 `libsql://` 抛「Unsupported database URL scheme」—— `os migrate` 因此在 CLI 已能启动的同一个 URL 上硬失败;同文件 docstring 仍称 driver-turso「ships separately in the Cloud distribution」

[baozhoutao]

发现于 #5602 的实施(PR #5819,domain:cli 车道)。落点在 packages/runtime,不属该单文件面,故另开。

现状

packages/runtime/src/standalone-stack.ts:

• detectDriverFromUrl()(约 :147)对 libsql:// 不认,落到末尾的 throw:
  [StandaloneStack] Unsupported database URL scheme: libsql://… . Supported schemes: memory://, postgres://, pg://, mongodb://, mongodb+srv://, file:
• 同文件 resolveDatabaseUrl()(约 :215)却把 process.env.TURSO_DATABASE_URL 列为 URL 来源之一 —— 即「读得进来、认不出去」:设了 TURSO_DATABASE_URL=libsql://… 的宿主拿到的是上面那条 throw。
• 文件头 docstring(:26-29)仍写着 @objectstack/driver-turso「ships separately in the ObjectStack Cloud distribution」。这句在 driver-turso 住在闭源 cloud 仓，却是开源 runtime 点名偏好的默认 driver — 建议把核心迁回本仓 #4645(driver 迁回本仓 packages/drivers/driver-turso)之后已不成立 —— 与 feat(drivers): driver-turso 迁回本仓公开发布，五个 IDataDriver 统一收进 packages/drivers/ (#4645 Phase A) #5618 Phase A 修掉的那批同类失真说法是同一族。

为什么现在值得记

PR #5819 落地后,CLI 的 os serve / os start 路径能从 libsql:// 构造 TursoDriver(可选包 + 动态 import)。但 os migrate 走的是另一条:packages/cli/src/utils/schema-migrate.ts:181 经 createStandaloneStack() 启动,utils/migrate-occupancy-gate.ts:25 也调 resolveStandaloneDatabase() —— 两者都要过 detectDriverFromUrl()。于是同一个 OS_DATABASE_URL=libsql://…:

• os start → 正常启动(装了 driver 包时);
• os migrate → Unsupported database URL scheme。

失败是响亮的(不是静默回退 SQLite),所以不是数据错位类,但对操作者是一条走不完的路径,也是新的两处口径分叉 —— 正是 #5602 记的那种。

可能的处置(未裁)

1. 让 detectDriverFromUrl() 也识别 libsql:// / *.turso.io,并沿用 CLI 侧同一形态(可选包 + 动态 import + 响亮缺包),DefaultDatasourcePlugin 的 host-factory 接缝已经是为此存在的;
2. 或明确 standalone stack 不支持 libSQL,那就同时删掉 TURSO_DATABASE_URL 这个 URL 来源(读得进认不出的组合无论如何都该消失),并把 docstring 改成真话。

无论哪条,ships separately in the Cloud distribution 那句都要改。

⚠️ 未认领,留给 PM 分诊(落点 packages/runtime,与 #5602 的 CLI 车道不同)。

---

Generated by Claude Code

[os-zhuang]

分诊:pm:queue + domain:cli。

落点锚定:packages/runtime/src/standalone-stack.ts 一个文件。packages/runtime 在 SKILL 域表的 cli 行(cli / runtime / verify / qa / types),不是 drivers —— 本单不改任何 driver-*,改的是 URL→driver 的分派面。

过时前提检查(origin/main@846ed1f,逐条实读):

• :157 [StandaloneStack] Unsupported database URL scheme: throw ✅ 仍在;
• :218 ?? process.env.TURSO_DATABASE_URL?.trim() ✅ 仍在 —— 「读得进、认不出」的组合成立;
• :26-28 docstring ✅ 仍在。全文是「libsql 由 @objectstack/driver-turso 提供,which ships separately in the ObjectStack Cloud distribution。The open-core runtime no longer dispatches libsql:// URLs」。

一处正文没点破、但决定方向的事实:该 docstring 不只是失真描述,它记录的是一个当初有理由的刻意姿态 —— 开源 runtime 不分派 libsql,因为 driver 不在本仓。#4645 把 driver 迁回本仓后,这条理由本身消失了;#5602 / PR #5819 又让 CLI 侧真的分派了 libsql://。所以正文的选项 2(「明确不支持」)今天等于保留一个前提已经不成立的排除,而选项 1 与仓库现状一致。预裁倾向选项 1,但这是倾向不是裁决:派发座位若判定「standalone stack 接 libSQL」构成能力扩张而非口径收敛,按 step 8 升级,不要在实施中默默选边。⚠️ 无论走哪条,TURSO_DATABASE_URL 这个 URL 来源与 ships separately 那句都必须同批处理 —— 只修 throw 会留下第三种口径。

查重:三仓 open issue / PR 各搜一遍(detectDriverFromUrl / standalone-stack / libsql / TURSO_DATABASE_URL)。#5602(pm:dispatched,PR #5819,cli 车道)是同族另一半 —— 其文件面在 packages/cli,与本单的 packages/runtime 不相交,不构成同文件串行;#5770(drivers,turso remote backfill)与 #4873(os migrate 退出码)均为不同现场。无影子单,不关重复。

给 cli 座位的选批提示:本单与 #5602 虽同族,os migrate 的两个调用点(cli/src/utils/schema-migrate.ts:181、utils/migrate-occupancy-gate.ts:25)在 #5819 落地后语义会变,派发前建议先确认 #5819 已合入,免得在两套 CLI 行为上同时推理。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code