generate:types hangs after completing (regression in 3.73.0, was fixed in 3.56.0)

[bobbyo]

Description

payload generate:types completes successfully (writes the output file) but the Node.js process never exits. It continues running at ~88% CPU indefinitely until manually killed.

This appears to be a regression of #13744, which was fixed in PR #13564 and released in v3.56.0.

Reproduction

1. Have a Payload 3.73.0 project with @payloadcms/db-postgres and a non-trivial schema (~19 plugins, ~20+ collections)
2. Run payload generate:types
3. The types file is written correctly and completely
4. The process never exits — it stays alive at ~88% CPU

In our case, we observed 4 concurrent generate:types processes (spawned by different build pipelines) all stuck for 40-60+ minutes each, consuming 4 CPU cores on an 8-core server until manually killed.

Evidence it completes successfully

• The output file payload-types.ts (2,984 lines / 70KB) is written correctly
• All types including self-referential relationships (e.g., grantedVia?: (string | null) | Share) are generated properly
• The process just never calls process.exit() afterward

Environment

• Payload: 3.73.0
• DB Adapter: @payloadcms/db-postgres@3.73.0
• Node.js: v20.19.6
• OS: Ubuntu 24.04 (Linux 6.14.0-1017-azure)
• Package manager: pnpm 10.x (monorepo with workspaces)

Expected behavior

payload generate:types should exit with code 0 after writing the types file, as was fixed in #13564.

Related issues

• generate:importmap and generate:types don't have process.exit #13744 — Original report of missing process.exit() in generate:types/generate:importmap
• feat: crons for all bin scripts, new jobs:handle-schedules script, more reliable job system crons #13564 — PR that fixed it in 3.56.0

[bobbyo]

Workaround

Until this is fixed upstream, wrapping the command with a timeout prevents zombie processes from accumulating:

timeout 120 payload generate:types

This lets the type generation complete (typically under 2 minutes) and force-kills the process if it hangs afterward.

[bobbyo]

Update: process.exit(0) IS present in 3.73.0 — the issue is different from #13744

After inspecting the source in node_modules, I can confirm that dist/bin/index.js in 3.73.0 does have process.exit(0) at line 51, after runBinScript returns. The fix from PR #13564 is present.

However, the process still hangs. The generateTypes function at line 117 completes and returns {}, but execution never reaches process.exit(0) at line 51.

The likely cause: config loading (line 85-90) imports the full Payload config which initializes plugins and the database adapter. In our case, that's @payloadcms/db-postgres + 19 plugins. Something in that initialization starts a background process (connection pool, watcher, cron, etc.) that either:

1. Blocks runBinScript from returning, or
2. Causes an unhandled rejection that prevents reaching process.exit(0)

This is not the same bug as #13744 — the exit call exists but is never reached. The generateTypes function itself completes successfully (the types file is written correctly).

Environment

• Payload 3.73.0
• @payloadcms/db-postgres 3.73.0
• 19 plugins loaded via config (form-builder, multi-tenant, nested-docs, redirects, seo, search, plus custom plugins)

Workaround

timeout 120 payload generate:types || true — since the types are written before the hang, this safely terminates the zombie process.

[bbmbriank]

For us, it is generate:schema that never exits. We're on v3.67.

[AlessioGr]

Hey, please attach a reproduction to the issue, then we'll investigate. Tested this in a few projects of ours, and the bin script exits as expected

[elghaied]

Hello , I have the same issue when I work in plugin template ,

Reproduction

The leak is triggered by any config-importing CLI command running with NODE_ENV=test — which is easy to hit because
Vitest sets NODE_ENV=test, and AI/agent tooling frequently runs generate:types in a shell where that's already exported.
The plugin template's dev/payload.config.ts spawns a 3-node MongoMemoryReplSet at config-import time, gated only on
NODE_ENV === 'test':

const buildConfigWithMemoryDB = async () => {
if (process.env.NODE_ENV === 'test') {
const memoryDB = await MongoMemoryReplSet.create({ replSet: { count: 3, dbName: 'payloadmemory' } })
process.env.DATABASE_URL = ${memoryDB.getUri()}&retryWrites=true
}
return buildConfig({ /* ... */ })
}
export default buildConfigWithMemoryDB()

Steps:

scaffold a plugin from the template, then:

NODE_ENV=test pnpm dev:generate-types

the command returns 0 in ~5s, but:

pgrep -a mongod

mongod ... --port 39161 --dbpath /tmp/mongo-mem-XXXX --replSet testset ...

mongod ... --port 40281 --dbpath /tmp/mongo-mem-YYYY --replSet testset ...

mongod ... --port 33841 --dbpath /tmp/mongo-mem-ZZZZ --replSet testset ...

Three mongod are left running and never shut down. Repeat the command (or interrupt a pnpm test:int / test:e2e run
mid-way, since Vitest also sets NODE_ENV=test) and they accumulate — I've ended up with leftover processes pinning ~100%
CPU each for hours.

Why it happens

payload's bin does await import(configPath), which executes the config — so under NODE_ENV=test the replica set is
spawned even though generate:types never needs a DB (generateTypes() only reads the config and writes the file). The bin
then calls process.exit(0), which kills the Node process but not the detached mongod children it spawned, and nothing
ever calls memoryDB.stop().

Confirmed scope

This is specific to the template config, not Payload core: a plain app config (no MongoMemoryReplSet branch) running
generate:types exits cleanly for every NODE_ENV (test/production/development), on both @payloadcms/db-mongodb and
@payloadcms/db-postgres with a real database. Only the NODE_ENV==='test' memory-server branch leaks.

Suggested fix

Gate the in-memory server on VITEST too (only set inside the Vitest runner, which owns the lifecycle), so one-shot CLI
commands can't spawn it:

if (process.env.NODE_ENV === 'test' && process.env.VITEST) {
// ... MongoMemoryReplSet.create(...)
}

Verified: with this gate, NODE_ENV=test pnpm dev:generate-types spawns 0 mongod and exits in ~3s. Ideally the memory
server should also be explicitly .stop()ed on teardown so even legitimate Vitest runs can't orphan it on a hard exit.