Fix authPlugin's uuid7 id pin: config, not a hardcoded constant by borisno2 · Pull Request #1550 · OpenSaasAU/stack

borisno2 · 2026-09-13T11:59:11Z

Summary

authPlugin hardcoded db.idField: 'uuid7' on every Auth list it injects, with no escape hatch:

An app-level db.idField default (e.g. cuid2, set to match a live better-auth install whose id columns already hold non-uuid text ids) never reached the Auth lists — the generator kept emitting a pg/uuid column regardless, breaking adopt-better-auth-tables's whole reason for existing.
The extendList branch (for a list the app declares itself under one of the derived keys) never applied the pin at all, so it could silently end up on a different idField than the injected branch, while the adapter's supportsUUIDs: true / supportsNumericIds: false were hardcoded regardless of which branch actually produced the list.
authPlugin gains an idField?: 'uuid7' | 'cuid2' option. Resolution order: explicit authPlugin({ idField }) → the app's own db.idField default → 'uuid7'. 'int autoincrement' is refused at config time (the Auth adapter treats every id as a string).
The addList and extendList branches are now required to agree: an app-declared list whose own resolved idField disagrees with the plugin's throws, naming both values.
adoptBetterAuthTables() grows a matching idField option, so adopting a text/cuid2-shaped live install is one line: adoptBetterAuthTables({ idField: 'cuid2' }).
The adapter's supportsUUIDs/supportsNumericIds (authIdCapabilities) are now derived from the resolved strategy instead of hardcoded, so they can never contradict the emitted column type.
ADR-0048 and ADR-0060 amended in place; new ADR-0070 records the decision. Changeset added for @opensaas/stack-auth (minor).

Test plan

New/updated unit tests in packages/auth/tests/config.test.ts, adopt-better-auth-tables.test.ts, and a new adapter-id-capabilities.test.ts
pnpm test in packages/auth — 518 passed, 81 skipped (pre-existing skips)
pnpm test in packages/core — 1757 passed
pnpm typecheck and pnpm build (root, turbo) — all 16 tasks succeed
pnpm lint / pnpm format / pnpm manypkg fix — clean

Closes #1239

🤖 Generated with Claude Code

https://claude.ai/code/session_01218dPJQasRpbcWL9w9fiZ8

Generated by Claude Code

…ide it authPlugin hardcoded db.idField: 'uuid7' on every Auth list it injects, with no escape hatch, so an app-level db.idField default (e.g. cuid2, to adopt a live better-auth install with text ids) never reached the Auth lists. The extendList branch also never applied the pin, so an app-declared list could silently disagree with the adapter's hardcoded supportsUUIDs/supportsNumericIds. authPlugin now resolves idField from an explicit authPlugin({ idField }), else the app's own db.idField default, else 'uuid7' — refusing a resolution of 'int autoincrement' (the Auth adapter treats every id as a string) and throwing when an app-declared list's own idField disagrees with the Auth lists' resolved strategy. The adapter's supportsUUIDs/supportsNumericIds are now derived from that resolved strategy instead of hardcoded. Closes #1239 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01218dPJQasRpbcWL9w9fiZ8

vercel · 2026-09-13T11:59:16Z

Deployment failed for project stack-docs with the following error:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day").

Learn More: https://vercel.com/open-saas?upgradeToPro=build-rate-limit

changeset-bot · 2026-09-13T11:59:16Z

🦋 Changeset detected

Latest commit: dd57cf8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 9 packages

Name	Type
@opensaas/stack-auth	Minor
@opensaas/stack-cli	Minor
@opensaas/stack-core	Minor
@opensaas/stack-rag	Minor
@opensaas/stack-storage-s3	Minor
@opensaas/stack-storage-vercel	Minor
@opensaas/stack-storage	Minor
@opensaas/stack-tiptap	Minor
@opensaas/stack-ui	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

chatgpt-codex-connector · 2026-09-13T11:59:17Z

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

borisno2 · 2026-09-13T12:00:21Z

The Vercel status check on this PR (stack-docs deployment) is failing with:

Resource is limited - try again in 24 hours (more than 100, code: "api-deployments-free-per-day")

That's the org's Vercel free-tier daily deployment quota being exhausted, not anything in this diff — this PR touches no docs content, and the failure names a resource limit rather than a build error. Nothing here for this PR to fix; it should clear on its own once the daily quota resets (or if/when the project moves to a paid plan). The real CI checks (test, e2e (postgres), e2e (dev-database), example-gates) are still running — I'll keep watching those.

Generated by Claude Code

borisno2

Single-pass review (no Agent-tool fan-out / subagent verify pass) of PR #1550 (959b078).

Worked through the diff line-by-line, traced resolveAuthIdField/authIdCapabilities against resolveIdStrategy/listIdColumn in core, checked the extendList id-agreement refusal against every fallback combination (explicit authPlugin({idField}), app-wide default, per-list override, singleton, int autoincrement), read the ADR-0048/0060 amendments and the new ADR-0070, and built+ran the full packages/auth suite (518 passed, 81 pre-existing skips) plus the three directly-relevant test files to confirm no regression.

No correctness bugs found — the id-resolution logic, the addList/extendList agreement check, and the derived supportsUUIDs/supportsNumericIds are internally consistent and well covered by the new tests. Left two low-severity notes inline (a reuse/drift-risk observation and a minor error-message attribution nit); neither blocks the change.

Generated by Claude Code

borisno2 · 2026-09-13T12:09:46Z

Review: #1550 — authPlugin's id strategy resolution (fixes #1239)

I cloned the PR branch, read the full diff, and traced the resolution logic against resolveIdStrategy/listIdColumn in packages/core/src/contract/derive.ts and id-boundary.ts. Summary against the five points requested:

1. `resolveAuthIdField` and the `addList`/`extendList` agreement check — correct

resolveAuthIdField(idField, appDefault) computes idField ?? appDefault ?? 'uuid7' and refuses 'int autoincrement'. This is exactly core's resolveIdStrategy's fallback chain (listConfig.db?.idField ?? config.db.idField ?? 'uuid7', minus the singleton case, which doesn't apply here). I walked the fallback matrix (explicit authPlugin({ idField }), app-wide default only, neither set, an app-wide 'int autoincrement' default with no override) and each resolves as documented.

The addList branch applies the single resolved idField uniformly to every entry the loop iterates — not just the four base models, but also the optional RateLimit list and any plugin-declared table (e.g. MCP OAuth tables) — since derive-auth-lists.ts sets no db.idField of its own on any of them, so this is a real fix, not one scoped only to the four base models.

The extendList agreement check (listIdColumn(context.config, listName)?.strategy !== idField) correctly generalizes beyond the direct "app default is int autoincrement" case: if only a single app-declared list under a derived key sets its own db.idField: 'int autoincrement' while the global default is fine, the agreement check still catches it (the earlier resolveAuthIdField refusal only fires when the global default resolves badly). I confirmed by tracing both paths that these two checks compose without a gap.

One rough edge, not a bug: if the app's global db.idField is 'int autoincrement' but an app-declared list (e.g. User) already sets its own valid override (e.g. 'cuid2'), resolveAuthIdField still throws immediately on the bad global default before the agreement check ever runs — the developer must add authPlugin({ idField: 'cuid2' }) explicitly even though one list already has the "right" value. This is defensible (nothing tells the plugin what strategy the other, not-yet-declared Auth lists like Session/Account should use just because User happens to override), but worth being aware isn't caught by a more targeted error message.

2. `authIdCapabilities` and reading only the `user` model's strategy — safe

authIdCapabilities derives { supportsUUIDs: strategy === 'uuid7', supportsNumericIds: false } from listIdColumn(config, registry.user)?.strategy. Reading only the user model to represent all Auth lists is safe because of the agreement check in point 1: every list in authLists (base models, RateLimit, plugin tables) is guaranteed to resolve to the same idField — either it's freshly added with the uniformly-resolved value, or it pre-existed and was checked to agree with that same value, or config-time construction throws. There's no path where user and, say, Session could disagree at the point authIdCapabilities runs. supportsNumericIds: false is correctly unconditional since 'int autoincrement' can never survive resolution.

3. New tests exercise the actual bug — yes

inherits the app default idField on every injected list when authPlugin sets none directly regresses the original defect (previously hardcoded uuid7 silently overrode a cuid2 app default; this test would have failed against the pre-fix code).
refuses an app default that resolves to int autoincrement and refuses an app-declared list whose own idField disagrees with the Auth lists exercise the two new refusals, not just the happy path.
adopts a live install on a text/cuid2 id strategy via adoptBetterAuthTables({ idField }) is a reasonable integration-level check of the adoption flow authPlugin's uuid7 pin overrides an app-level db.idField and misses the extendList branch #1239 was actually about.
authIdCapabilities tests cover uuid7 (default), explicit cuid2, and app-wide cuid2 default — the three inputs that matter to that function.

These read as real regression coverage, not restatements of the implementation.

4. ADR consistency — consistent

ADR-0070's decision section, and the ADR-0048/0060 blockquote amendments, match the shipped code point-for-point: the resolution order, the 'int autoincrement' refusal, the extendList-never-touches-db invariant (ADR-0013 precedent), and authIdCapabilities reading the user model's strategy to speak for all Auth lists. I didn't find any claim in the ADRs the diff doesn't back up.

5. Edge cases — plugin-derived tables and `RateLimit` — no gap found

Confirmed by reading derive-auth-lists.ts and the addList/extendList loop in plugin.ts: the resolved idField is applied to every entry getAuthLists(...) returns, which already includes RateLimit and any better-auth-plugin-declared table, not just the four base models — so there's no special-casing gap for those. The extendList agreement check is likewise generic over listName, so an app that itself declares RateLimit (or a plugin table) under its derived key gets the same mismatch protection as User.

Minor, non-blocking notes (already left inline)

packages/auth/src/config/plugin.ts:19 — resolveAuthIdField re-implements resolveIdStrategy's exact fallback chain rather than reusing it. I confirmed resolveIdStrategy itself isn't exported from @opensaas/stack-core (only listIdColumn, which needs an existing list config and can't answer "what would a not-yet-added list resolve to"), so this duplication is closer to unavoidable than sloppy given the current export surface — but it is a drift risk if core's fallback order ever changes. Worth a cross-reference comment or exporting resolveIdStrategy for reuse.
packages/auth/src/config/plugin.ts:108 — the mismatch error always says the conflicting list "is declared by the application," but the check only tests context.config.lists[listName] truthiness. If an earlier-running plugin (not the application) registered that list key first, the message misattributes the conflict. Not a functional bug — just a wording nit if that scenario is reachable in practice.

Verdict

No blocking issues found. No regressions in the packages/auth test suite. The two notes above are optional polish, not required changes.

Generated by Claude Code

Cross-reference resolveIdStrategy in the reimplemented fallback chain, and soften the extendList mismatch error to not assume the application (rather than an earlier-running plugin) declared the conflicting list. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01218dPJQasRpbcWL9w9fiZ8

vercel · 2026-09-13T12:12:39Z

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

Project	Deployment	Actions	Updated
stack-docs	Ready	Preview	Sep 13, 2026 12:13pm UTC

github-actions · 2026-09-13T12:30:26Z