In
`@apps/backend/src/app/api/latest/connected-accounts/`[user_id]/[provider_id]/[provider_account_id]/access-token/crud.tsx:
- Around line 155-179: The refresh-token rotation is non-atomic: the sequence
around prisma.oAuthAccessToken.create, prisma.oAuthToken.update and
prisma.oAuthToken.create can race under concurrent getAccessToken calls; wrap
the rotation (invalidate old refresh token and insert new refresh token and
access token) in a single database transaction (using prisma.$transaction) or
use an optimistic lock (e.g., check and update a version/isValid predicate in
the WHERE clause) when calling prisma.oAuthToken.update so only one caller can
mark the old token invalid and create the new token; ensure the transaction
includes the access token insert and the refresh-token update/create to
guarantee atomicity and avoid duplicate refresh tokens.

In `@apps/dev-launchpad/public/index.html`:
- Line 368: The href's nested template mistakenly includes a literal "$p" prefix
in the subdomain construction (the expression `$p${stackPortPrefix}.`) which
results in invalid hostnames; update the href template so the conditional uses
either an empty string or the plain port-prefix subdomain without the stray "$"
(i.e., replace `$p${stackPortPrefix}.` with `${stackPortPrefix}.` or otherwise
remove the leading "$"), leaving the rest of the expression
(withPrefix(app.portSuffix), app.path, and the importance-based class logic)
unchanged.

In `@apps/e2e/tests/backend/endpoints/api/v1/connected-accounts.test.ts`:
- Around line 898-905: The test titled "should return 404 when trying to list
connected accounts for non-existent user via server access" is misleading
because it asserts response.status is 400 and response.body.code is
"SCHEMA_ERROR"; change the test description string to reflect the actual
behavior (e.g., "should return 400 when trying to list connected accounts for
non-existent user via server access") so the test title matches the assertions
in the it(...) block that calls niceBackendFetch and checks response.status and
response.body.code.
- Around line 877-896: The test title is incorrect: update the it(...)
description in the test block where the request to
"/api/v1/connected-accounts/me" is made (the test starting with "should return
403 when unauthenticated user tries to list connected accounts") to reflect the
actual behavior/status (400 and CANNOT_GET_OWN_USER_WITHOUT_USER) — e.g., change
the string to "should return 400 when unauthenticated user tries to list
connected accounts" so the test title matches the assertion and response.

In `@examples/demo/src/app/connected-accounts/page.tsx`:
- Around line 47-49: The displayed access token always gets "..." appended even
when its length is ≤ 50; update the rendering logic around accessToken (the
variable used in the JSX pre block) to conditionally append the ellipsis only
when accessToken.length > 50 (e.g., show accessToken.slice(0,50) + "..." when
longer, otherwise show the full accessToken without the suffix) so short tokens
are not misleadingly truncated.

In `@packages/template/src/lib/stack-app/apps/implementations/client-app-impl.ts`:
- Around line 1424-1443: getConnectedAccount currently computes scopeString but
ignores it in the object-based branch; either remove scopes from that overload
or forward scopeString when building/returning the OAuthConnection. Locate the
object-branch in getConnectedAccount and when you resolve the connected account
(where the code currently returns found), call the same token-fetch/creation
path used elsewhere but pass options?.scopes (or scopeString) into the
token/cache call (e.g., into the token-fetch cache or
_createOAuthConnectionFromCrudItem invocation) so the requested scopes are
honored; alternatively, remove the scopes option from the object-based overload
signature at the top to prevent callers from passing scopes that will be
ignored. Ensure the unique symbols getConnectedAccount and scopeString are
updated accordingly.
- Around line 1526-1534: The bare catch around existing.getAccessToken()
swallows all errors; change it to catch (err) and only handle the expected
token-invalid/revoked error (e.g., check err.name/err.message for the OAuth
"invalid_grant"/"invalid_token"/"refresh token" signatures or a specific
AssertionError), allowing other errors (network/timeouts, server errors) to be
rethrown or logged and propagated; implement a small predicate like
isTokenInvalidError(err) and use it inside the catch to decide whether to fall
through to the link flow or rethrow, and ensure you reference the existing
variable and its getAccessToken method when applying this change.
- Around line 1541-1546: In useOrLinkConnectedAccount, remove the unsafe type
cast and non-null assertion: avoid casting provider with "as ProviderType" and
replace the "result!" assertion with a defensive null-check (e.g., return result
?? throwErr("useOrLinkConnectedAccount: cache returned null") ). If you cannot
immediately reconcile string vs ProviderType for
app._currentUserOAuthConnectionCache keys, add a TODO comment explaining the
mismatch and leave a safe conversion or runtime check instead of using "as";
ensure all references to ProviderType and app._currentUserOAuthConnectionCache
are updated accordingly.
- Around line 1454-1477: The hook useConnectedAccount currently calls
useAsyncCache conditionally which violates Rules of Hooks; modify
useConnectedAccount to invoke both useAsyncCache hooks unconditionally — one
against app._currentUserConnectedAccountsCache (with [session] as args) and one
against app._currentUserOAuthConnectionCache (with [session, idOrAccount,
scopeString, options?.or === 'redirect'] or appropriate dummy args when
idOrAccount is an object) — then pick and return the correct result
(object-based match from connectedAccounts if idOrAccount is the object shape,
otherwise the provider-based OAuthConnection); alternatively you can split into
two hooks like useConnectedAccountByProvider and useConnectedAccountByObject to
avoid dummy fetches.

In `@packages/template/src/lib/stack-app/apps/implementations/server-app-impl.ts`:
- Around line 442-470: The object-overload `scopes` option is ignored because
_createServerOAuthConnectionFromCrudItem hardcodes the cache key scope element
to "" in getAccessToken and useAccessToken; update
_createServerOAuthConnectionFromCrudItem to accept/receive the requested scopes
(e.g. add a scopes parameter or accept it via the calling path) and include
those scopes when calling
app._serverUserOAuthConnectionAccessTokensByAccountCache.getOrWait and
useAsyncCache (replace the "" element with a deterministic representation of the
scopes array, e.g. joined string or stable key), so getAccessToken and
useAccessToken actually respect the `{ scopes?: string[] }` passed to
getConnectedAccount/getOrLinkConnectedAccount; alternatively, if you prefer to
keep the current cache shape, remove the `{ scopes?: string[] }` option from the
object-based getConnectedAccount/useConnectedAccount overloads to avoid the
mismatch.
- Around line 508-531: The current useConnectedAccount implementation
conditionally calls useAsyncCache in two branches which violates React hooks
ordering; refactor so both useAsyncCache hooks are invoked unconditionally and
then select the appropriate result based on idOrAccount's shape: always compute
scopeString, call useAsyncCache(app._serverUserConnectedAccountsCache, [crud.id]
as const, "user.useConnectedAccount()") to get connectedAccounts and also call
useAsyncCache(app._serverUserOAuthConnectionCache, [crud.id, idOrAccount,
scopeString, options?.or === 'redirect'] as const, "user.useConnectedAccount()")
to get oauthConnection, then if idOrAccount is the object shape (has provider
and providerAccountId) filter connectedAccounts for the matching
provider/providerAccountId and return that (or null), otherwise return the
oauthConnection result; keep all original identifiers (useConnectedAccount,
useAsyncCache, app._serverUserConnectedAccountsCache,
app._serverUserOAuthConnectionCache, crud.id, scopeString, options?.or) so the
hooks are always called in the same order.

In `@apps/e2e/tests/backend/endpoints/api/v1/connected-accounts.test.ts`:
- Around line 503-507: The test title string currently reads "should return 404
when trying to get access token for non-existent provider_account_id" but the
assertion/snapshot expects a 400 with OAUTH_CONNECTION_NOT_CONNECTED_TO_USER;
update the test description in the it(...) call to reflect the actual expected
status and error (for example: "should return 400 when getting access token for
non-existent provider_account_id (OAUTH_CONNECTION_NOT_CONNECTED_TO_USER)") so
the title matches the assertion in the test handling code.

In `@examples/demo/src/app/connected-accounts/page.tsx`:
- Around line 101-214: Replace the broad try/catch + any casts in
handleGetByProvider, handleGetByBothIds and handleLink with
runAsynchronouslyWithAlert: validate that provider is a non-empty string (reject
or show alert if not) instead of using provider as any, remove the `: any` error
casts, and wrap the async calls (user.getConnectedAccount(...) and
user.linkConnectedAccount(...)) inside runAsynchronouslyWithAlert to surface
errors; ensure providerAccountId handling remains the same for getByBothIds and
that scopes are parsed the same in handleLink before passing to
user.linkConnectedAccount.

In `@packages/stack-shared/src/known-errors.tsx`:
- Around line 1130-1138: The OAuthAccessTokenNotAvailable constructor currently
doesn't persist the details field so deserialization (constructorArgsFromJson)
loses provider/details and can throw; update the createKnownErrorConstructor
call for OAuthAccessTokenNotAvailable so the constructor accepts and stores a
details string (include it in the error payload/state returned by the factory)
and make the JSON-to-args function resilient by guarding missing
json.provider/json.details (e.g., default to empty string) so round-tripping via
constructorArgsFromJson works without throwing.

In `@packages/template/src/lib/stack-app/apps/implementations/client-app-impl.ts`:
- Around line 394-397: Replace the non-null assertion on user in the block that
finds the OAuth provider: instead of user!.oauth_providers, assert user exists
with a defensive check (e.g., user ?? throwErr("Expected user to be present when
hasConnection is true in client-app-impl")) and likewise ensure the found
matchingProvider is present — do not default providerAccountId to an empty
string; if matchingProvider is missing throw an explicit error (e.g., throwErr
or new Error) that includes options.providerId and the context (function/class:
client-app-impl handling connections) so broken assumptions are surfaced
clearly.