fix(service-datasource): read a turso datasource's bound secret into authToken (#8152)

[huangyiirene]

Closes#8152.

The defect

After #8078 a new turso datasource could not be authenticated by any route an author has.

#7990/#8078 made config.authToken a refused inline credential (z.never()) at every authoring door — exactly like the SQL drivers' config.password — and diverted the author to the secret binder: bind the credential, keep only external.credentialsRef on the record. The connect path resolves that ref and hands the cleartext to the driver factory as spec.secret. Nothing on the turso path read it.TURSO_CONFIG_READERS.authToken consulted config.authToken alone, so the resolved secret was dropped and the connection was attempted unauthenticated:

buildTursoDriverConfig({driver: 'turso', config: {url: 'libsql://my-db.turso.io'},
secret: 'THE-BOUND-JWT', external: {credentialsRef: 'sys_secret:abc'}})
→ { url: 'libsql://my-db.turso.io' } // no authToken

Inline refused at the door, bound dropped at the builder — no route left.

The fix — 5 lines, parity with the siblings

authToken now reads spec.secret first and falls back to config:

authToken: ({ spec, config })=>spec.secret
? spec.secret
: typeofconfig.authToken==='string'&&config.authToken
? config.authToken
: undefined,

Exact parity with the postgres / mysql / mongodb arms in this same package (spec.secret ? { password: spec.secret } : cfg.password ? { password: cfg.password } : {}). No new mechanism, no spec change, no second binder slot: spec was already on TursoConfigSource for schemaMode, so the credential had been reaching this function all along.

config.authToken stays readable, and not only for legacy stored rows. The CLI and standalone hosts translate OS_DATABASE_AUTH_TOKEN / TURSO_AUTH_TOKEN into a config: { url, authToken } on a definition they construct themselves (packages/cli/src/utils/storage-driver.ts:451), which never meets the authoring schema that refuses the key. Dropping that arm would break the default datasource's env credential — a live route, refused only for authors. An empty spec.secret is treated as unset and falls through to config, matching this builder's existing rule for string keys.

Reverse verification — readings on origin/main (a0fdc56)

Measured by reverting the 5-line fix in place and re-running, not inferred.

RED on main (6) — carry the defect:

Pin	Reading on main
turso-driver-config: reads the bound secret into authToken	{ url: 'libsql://my-db.turso.io' } — assertion on authToken failed
turso-driver-config: bound secret beats a stale inline config.authToken	got 'STALE-INLINE'
turso-driver-config: binds to authToken ONLY, never encryptionKey	key set was ['url'], expected ['authToken','url']
authoring (new): a datasource created through the real admin door with a bound secret reaches the driver with an authToken	spec.secret arrived; the builder emitted no authToken
authoring (new): the bound route is the ONLY one a newly authored datasource has	half one (door refuses inline) passed; half two failed — the dead end
authoring (new): the credential lands in one slot, not two	red via its authToken half

GREEN on main (15) — guard behaviour that must not change:

• feat(spec)!: refuse inline credentials at publish — driver config + connector authoring door (#7990, spec half) #8078's inline refusal still fires at createDatasource AND at updateDatasource, and its guidance still names both external.credentialsRef and the secret binder. This card restores the alternative route; it must not reopen the inline one.
• config.authToken is still read when no secret is bound — guards the host env-var route above.
• postgres / mysql / mongodb still read spec.secret as the password, and a bound secret still beats an inline config.password — the sibling arms this change takes its shape from, and unpinned until now.
• A turso config with no credential at all is still accepted (the shape a bound datasource stores).

The vacuity trap, and how the pins avoid it

Stored rows still work — stored config bypasses the parse — so any case built on an already-existing turso datasource is green on main too. Every red pin therefore starts at createDatasource(): authored through the real admin door, credential bound through the real secret binder, resolved through the real connect path.

The encryptionKey guard is asserted beside the authToken assertion rather than alone, for the same reason: expect(config).not.toHaveProperty('encryptionKey') on its own is green on main for the useless reason (main emitted neither key).

One seam, stated in the test header rather than hidden: the factory's real turso arm cannot run in this package — @objectstack/driver-turso is deliberately not resolvable from it, and the missing-package arm's own pin depends on that. So the end-to-end pins capture the spec the connect path actually hands factory.create() and run the real buildTursoDriverConfig on exactly that spec, which is the line the factory arm itself executes. Both halves are production code; only the new TursoDriver(...) call is absent.

Scope — the four boundaries held

• ⛔ encryptionKey untouched. Different secret (AES-256 key for a local file vs. a bearer token for a remote), one binder slot, and whether it needs a second is a separate decision. A pin now fails if a later change resolves that by guessing one bound secret means both slots.
• ⛔ Neither multi-slot shape built (external.credentials: {slot → ref}, JSON-bag ref).
• ⛔ feat(spec)!: refuse inline credentials at publish — driver config + connector authoring door (#7990, spec half) #8078's refusal not relaxed — pinned green in both places.
• ⛔ fix(service-datasource): stop serving stored credentials on the datasource read path, and fix the false "credential-stripped" claim (#8081) #8126's read-time redaction of encryptionKey not modified.
• ⛔ packages/spec/src/** not touched. The contract needs no change: spec.secret is already on DatasourceConnectionSpec and the connect path already resolves it.

Gates

Gate	Reading
check-test-source-alias	OK — 72 packages with tests scanned, 62 registered. @objectstack/spec was already this package's registry entry, so the new file's @objectstack/spec/data import adds nothing; KNOWN_UNALIASED_TEST_IMPORTSnot widened.
check:type-check-coverage	OK — 64/77 packages type-checked, 13 in DEBT (442 frozen), 1 exempt.
check:type-check-debt (--re-measure)	OK — 33 entries re-measured, 1966 raw errors, none above its ceiling. Required building the workspace closure first, as lint.yml does. The 9 surplus notices are pre-existing entries in unrelated packages.
tsc --noEmit (service-datasource)	clean — this package does not hide its tests from tsc, so the new file is type-checked
eslint	clean on all three changed files
ADR-0112 envelope	not applicable — no refusal surface changed and no error code added
Changeset	.changeset/turso-bound-secret-authtoken.md (patch)

Untouched: content/docs/releases/**, docs/adr/**, .claude/skills/**, skills/**.

Tests

Package	Result
@objectstack/service-datasource	16/16 files, 376/376 cases
@objectstack/runtime	145/145 files
@objectstack/cli	115/115 files

Runtime and CLI are included because they are the other two readers of this builder (turso-driver-factory.convergence.test.ts, storage-driver.test.ts).

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectstack	Ignored		Aug 12, 2026 7:09pm

[github-actions]

📓 Docs Drift Check

No hand-written docs reference the 1 changed package(s). ✅