Nuxt Prerendering silently stalls on 2.1.0, build exits 0, no `.output/server`

[lucpotage]

Environment

• Nuxt: 4.5.1
• @nuxt/image: 2.0.0 ✅ / 2.1.0 ❌
• nitropack: 2.13.4 (identical in both cases)
• Node: 24.18.1
• Package manager: pnpm
• OS: macOS (darwin arm64)

Prepared with Claude Code

Reproduction

Large statically-generated site (thousands of prerendered routes, several hundred
<NuxtImg>//_ipx/... routes), built with nitro.static: true (also reproduces
with an explicit prerender route list, not just crawlLinks).

With @nuxt/image@2.1.0, the prerender log stops mid-run with no error, and the
process exits 0:

[nitro]   ├─ /_ipx/_/some-image.png (7ms)
<no further output — exit code 0>

• Prerendered N routes in Xs is never printed
• .output/server/ is never created (build() never runs)
• Deterministic: stops after the same number of routes on every run

Configuration that works

"@nuxt/image": "2.0.0"

→ prerender completes, .output/server/ is built normally:

[nitro] ℹ Prerendered N routes in Xs
[nitro] ✔ Nuxt Nitro server built

Configuration that does NOT work

"@nuxt/image": "2.1.0"

→ prerender silently stalls partway through, .output/server/ is missing. Every
other dependency and all config was kept byte-identical between the two runs.

Expected behavior

The build should either complete, or fail loudly (non-zero exit code / error).

Actual behavior

The build hangs and exits 0 as if it succeeded, producing an incomplete
.output/ with no server — CI reports green on a broken build.

Additional notes (suspected cause)

Diffing 2.0.0...2.1.0, the only prerender/IPX-relevant change is src/runtime/server/routes/_ipx.ts switching from ipx@^3.1.1's native H3 handler (createIPXH3Handler) to ipx@4.0.0-beta.1's createIPXNodeHandler, bridged through h3's fromNodeMiddleware. ipx v4's rewrite also dropped the try/catch that used to guarantee every request settled in v3. Nitro's prerender queue has no per-route timeout, so a request that never settles hangs the whole crawl silently — which matches what we see exactly.

ipx@4.0.0-beta.1 is still the latest ipx release (main is only 2 README commits ahead of that tag), so this isn't already fixed upstream.

Workaround: pin @nuxt/image to 2.0.0.

[coderabbitai]

🔗 Related PRs

#2094 - feat(deps): migrate to ipx v4 [merged]
#2281 - feat!: migrate to Nuxt 5 [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[luc122c]

Perhaps one for @pi0 to look at? The migration to ipx v4 in #2094 changed how the handler is created:

v2.0.0 (working):

import { createIPX, createIPXH3Handler, ... } from 'ipx'
const ipxHandler = createIPXH3Handler(ipx)  // Native h3 handler
return useBase(opts.baseURL, ipxHandler)

v2.1.0 (broken):

import { createIPX, createIPXNodeHandler, ... } from 'ipx'
const nodeHandler = createIPXNodeHandler(ipx, {...})  // Uses srvx internally
return fromNodeMiddleware(nodeHandler as NodeListener)  // h3 wrapper

The problem is that createIPXNodeHandler uses srvx's toNodeHandler which converts a fetch handler to a Node.js HTTP handler. When wrapped with h3's fromNodeMiddleware, there's a potential for requests to hang if:

• The srvx handler returns a Promise that doesn't settle
• The next callback in h3's callNodeListener is never invoked
• There's an exception that isn't caught properly

[danielroe]

this is, I think, resolved in v1.0.5 of node-mock-http (in unjs/node-mock-http#32) - can you check your lockfile and update it if so?

[luc122c]

can you check your lockfile and update it if so

I refreshed my lockfile on my local reproduction, and it seems to have resolved it. Prerendering continues as normal.