Repository navigation
runtime(standalone-stack): detectDriverFromUrl() 对 libsql:// 抛「Unsupported database URL scheme」—— os migrate 因此在 CLI 已能启动的同一个 URL 上硬失败;同文件 docstring 仍称 driver-turso「ships separately in the Cloud distribution」 #5820
Description
发现于 #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 记的那种。
可能的处置(未裁)
- 让
detectDriverFromUrl()也识别libsql:///*.turso.io,并沿用 CLI 侧同一形态(可选包 + 动态 import + 响亮缺包),DefaultDatasourcePlugin的 host-factory 接缝已经是为此存在的; - 或明确 standalone stack 不支持 libSQL,那就同时删掉
TURSO_DATABASE_URL这个 URL 来源(读得进认不出的组合无论如何都该消失),并把 docstring 改成真话。
无论哪条,ships separately in the Cloud distribution 那句都要改。
packages/runtime,与 #5602 的 CLI 车道不同)。
Generated by Claude Code
Activity
os-zhuang commentedon Aug 6, 2026
分诊:
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-28docstring ✅ 仍在。全文是「libsql 由@objectstack/driver-turso提供,which ships separately in the ObjectStack Cloud distribution。The open-core runtime no longer dispatcheslibsql://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
refactor(runtime,cli): give the optional Turso/libSQL loader one owner (