RootPage: config.admin resolves to {} on every request in production, causing 'Cannot destructure property routes of {}' — app config's own module import, not getPayload()'s

[mamathakonduru]

Describe the Bug

In production (Next.js App Router, standard next start, not standalone output), every request to /admin/* deterministically crashes:

TypeError: Cannot destructure property 'routes' of '{}' as it is undefined.
    at RootPage (.next/server/app/(payload)/admin/[[...segments]]/page.js)
    digest: '987409242'

TypeError: Cannot destructure property 'config' of '<awaited-value>' as it is undefined.
    at generatePageMetadata-related fn (.next/server/app/(payload)/admin/[[...segments]]/page.js)
    digest: '1425221127'

This traces to RootPage's own top-level destructure (@payloadcms/next/dist/views/Root/index.js):

export const RootPage = async ({ config: configPromise, importMap, params: paramsPromise, searchParams: searchParamsPromise }) => {
  const config = await configPromise;
  const {
    admin: { routes: { createFirstUser: _createFirstUserRoute }, user: userSlug },
    routes: { admin: adminRoute }
  } = config;
  ...

config.admin is resolving to {} (an empty object, not undefined) — i.e. config itself is a real, truthy object, but its admin property lacks the routes sub-object that sanitizeConfig's addDefaultsToConfig is supposed to populate unconditionally.

Notably

• The REST API route (/api/[...slug]) in the same app, same deployment, same request window, works correctly — it resolves config via Payload's getPayload() singleton (req.payload.config), not via the raw @payload-config module import.
• Our apps/cms/src/app/(payload)/admin/[[...segments]]/page.tsx follows the officially scaffolded pattern exactly:

  import config from '@payload-config'
  import { RootPage, generatePageMetadata } from '@payloadcms/next/views'
  import { importMap } from '../../importMap.js'
  
  export const generateMetadata = ({ params, searchParams }) => generatePageMetadata({ config, params, searchParams })
  const Page = ({ params, searchParams }) => RootPage({ config, params, searchParams, importMap })
  export default Page

• payload.config.ts's default export is a single export default buildConfig({...}) — buildConfig (from payload/dist/config/build.js) is async function buildConfig(config): Promise<SanitizedConfig>, internally calling sanitizeConfig(config), whose first synchronous step is addDefaultsToConfig(incomingConfig) — which unconditionally sets admin.routes defaults (createFirstUser: '/create-first-user', etc.). We traced this directly in node_modules/payload/dist/config/sanitize.js and defaults.js — nothing conditional should cause admin.routes to be dropped.
• We could not determine, from static source reading alone, why the config value awaited inside RootPage's own module differs from the one Payload's getPayload() singleton produces from the same buildConfig() promise export — our leading hypothesis is that Next.js compiles the admin page/metadata bundle and the REST API route bundle as separate serverless-style chunks, each independently re-evaluating payload.config.ts, and something about that independent re-evaluation (possibly concurrent/racy) produces an incompletely-resolved config specifically in the page/metadata bundle. We were not able to confirm this without a debugger attached to a live reproduction.

Why this is easy to miss

Before we had run any Payload migrations, our /admin route 500'd earlier in the request lifecycle (relation "users" does not exist), so this create-first-user redirect code path was never actually exercised. Once the schema existed and the users table was genuinely empty, every /admin request started taking this exact path — turning what might otherwise show up as a rare, easy-to-miss race into a 100%-reproducible outage the moment a fresh Postgres-backed deployment has zero users.

To Reproduce

1. Fresh Postgres database, prodMigrations wired into postgresAdapter() (migrations apply via payload.init() on server boot — no separate payload migrate step).
2. NODE_ENV=production, next build && next start.
3. Ensure the users table exists but has zero rows.
4. Request /admin or /admin/create-first-user — the request should redirect toward create-first-user and crash with the above error.

Environment

• Payload: 3.85.1
• @payloadcms/next: 3.85.1
• @payloadcms/db-postgres: ^3.0.0
• Next.js: 15.4.11
• React: 19.x / React DOM 19.x
• Node: 20.x (Railway-hosted, no custom Dockerfile — platform-managed build)
• Adapter: @payloadcms/db-postgres with prodMigrations

Expected behavior

/admin/create-first-user should render normally when the users table exists and is empty — this is the standard first-run admin bootstrap flow.

Additional context

Happy to share more evidence (deploy logs, exact digests) or run a targeted reproduction if a maintainer can point at what in sanitizeConfig's call chain could differ between RootPage's config import and getPayload()'s resolved config within the same Next.js app.

[mamathakonduru]

Update: reproduced locally, config resolution ruled out as the cause

Set up a local reproduction (disposable Postgres via Docker, next build && next start against a fresh empty users table) and instrumented every config-resolution checkpoint in the chain with temporary logging. Results:

• RootPage's own const config = await configPromise; const { admin: { routes: {...} }, routes: {...} } = config — succeeds, confirmed via a log placed immediately after the destructure, printing the extracted adminRoute value correctly (/admin).
• initReq's local config variable, right before calling getPayload({config, ...}) — fully populated, admin.routes.createFirstUser present.
• getPayload's options.config at entry — fully populated.
• BasePayload.init's this.config = await options.config — fully populated, confirmed via a log immediately after assignment.

So the config is complete and correct at every point from @payload-config's module-level promise all the way through BasePayload.init() setting this.config. The 500 (Cannot destructure property 'routes' of '{}', same digest across multiple rebuilds) still occurs on every request despite this — meaning the failure is not in config sanitization/resolution at all. It must be happening later in RootPage's flow (view selection / getRouteData / getClientConfig / the child view component actually rendered for create-first-user) or during React's deferred rendering of the JSX tree RootPage returns.

Also confirmed: handleAuthRedirect (which has an identically-shaped destructure) is not being called for this route — ruled that out as the site too.

Tried reproducing in next dev for a readable (non-minified) stack trace instead of guessing from the production bundle's minified positions, but dev mode introduced its own noise (86s first-compile times, an unrelated Monaco CodeEditor.tsx destructure error from lazy-compiled admin UI chunks) that didn't cleanly isolate the same crash — will need either a debugger attached mid-request in production mode, or a maintainer's guidance on where else in the RootPage → view-resolution → render chain a config.admin-shaped destructure could still be failing after BasePayload.init has a fully sanitized config in hand.

Reproduction repo/steps available if useful — happy to share the instrumented diff.

[JarrodMFlesch]

Can you share a reproduction? i.e. a forked branch that we can pull down and test this out with?

[mamathakonduru]

Update: false alarm — root cause was in our own project, not Payload

Found it via local reproduction with server source maps enabled (`experimental.serverSourceMaps: true`), which gave a readable, unminified stack trace instead of guessing from the production bundle.

Root cause: our project's `src/app/(payload)/layout.tsx` was a stub that never wrapped the admin route tree in Payload's own `RootLayout`:

```tsx
// what we had — completely wrong, doesn't establish any Payload providers
export default function PayloadLayout({ children }: { children: React.ReactNode }) {
return <>{children}</>
}
```

`RootLayout` (from `@payloadcms/next/layouts`) is what establishes `RootProvider`/`ConfigProvider` — the React context that `PageConfigProvider` and other admin UI components read via `useConfig()` (`use(RootConfigContext)` in `@payloadcms/ui/dist/providers/Config/index.js`). With no provider ancestor, `use()` returns the context's default value, and downstream destructures of `config.admin.routes` throw exactly this error — deterministically, on every request, since there was never a provider to begin with.

This also fully explains the earlier "rare, self-healing" behavior we originally reported issue #45 for: before our schema-creation fix, the admin route crashed even earlier (missing Postgres schema), so this broken-provider code path was never actually reached in production. Once the schema existed, every request reached it and crashed 100% of the time.

Fix: replaced the stub with the standard scaffolded layout:

```tsx
import type { ServerFunctionClient } from 'payload'
import config from '@payload-config'
import '@payloadcms/next/css'
import { handleServerFunctions, RootLayout } from '@payloadcms/next/layouts'
import { importMap } from './importMap.js'

const serverFunction: ServerFunctionClient = async function (args) {
'use server'
return handleServerFunctions({ ...args, config, importMap })
}

const Layout = ({ children }: { children: React.ReactNode }) => (

{children}

)

export default Layout
```

Verified via local repro (disposable Postgres, `next build && next start`, empty `users` table): 6/6 requests to `/admin/create-first-user` now return 200 with correct content.

Apologies for the noise — the earlier evidence I posted (proving config resolution was fine through `BasePayload.init`) was accurate, it just correctly ruled out the wrong layer; the actual break was in the React context tree above where I was looking, in our own project's layout file rather than in Payload's config sanitization. Closing this out as not a Payload bug. Thanks for the patience.