3.0.2: background renderPages job blocks the Node event loop for ~8 min, 2.x import fails with 499/502

[HermessNRJ]

Summary

Importing a Wiki.js 2.5.317 .wkbackup into Wiki.js 3.0.2 fails during the pages stream. While the import runs, the background renderPages job freezes the server process for about 8 minutes at a time:

• no log output at all;
• CPU pinned at 1 core;
• HTTP requests hang, including /_ready and /_live.

The in-flight POST /_api/import/sessions/<id>/sites/<id>/streams/pages request then fails with 499 (client gave up after ~50 s) or 502, and the import aborts.

Environment

• Wiki.js 3.0.2, official Helm chart wiki 3.0.2, 1 replica
• Kubernetes, PostgreSQL 17 (external)
• Resources: requests 200m CPU / 1Gi memory, limit 2Gi memory, no CPU limit. The node is at ~60% CPU, so the pod is not throttled.
• Source: Wiki.js 2.5.317 export, about 3000 pages (fr + en), 692 folders, ~640 MB package
• Import options: Assets, Pages, Comments, History; Overwrite on conflict; Convert to markdown (it's the same with only Pages + Assets)

Steps to reproduce

1. Start an import of a large 2.x package.
2. The Pages stream begins. Imported pages are queued for re-render in the background.
3. About 30 s into the pages stream, the process stops responding for ~8 min.

Observed logs (server)

16:26:36  (import: Pages: starting (3016 records)...)
16:27:09  info: Render queue: rendered 220 pages.
          --- nothing logged for 8 minutes, CPU ~990m ---
16:35:08  error: Failed to render page <id> (<path>): Rendering did not finish within 30 seconds.
16:35:08  warn: Failed to complete job <id>: renderPages [ FAILED ]
16:35:08  warn: Error: The task did not finish within 300s, nor stop within 60s of being asked to. It is still running and cannot be stopped from here; no other run of it will start on this instance until it ends.
              at abandon (file:///wiki/backend/core/scheduler.ts:341:14)
16:35:09  error: Render queue: 1 of 88 queued pages failed to render and were left as they were.
16:35:09  warn: The abandoned run of renderPages has finished after all.

The same pattern shows up on every attempt (15:47→15:55, 15:55→16:03, 16:27→16:35). One earlier run ended with:

warn: The abandoned run of renderPages failed: Navigation timeout of 30000 ms exceeded

The page named in "did not finish within 30 seconds" changes every time, and its content is trivial (a few paragraphs and two images). It looks like it is just the page that happened to be in progress when the timer finally fired.

Client side

Request failed due to a network error: POST .../streams/pages   (proxy log: 499 after 50.4 s)
Request failed with status code 502: POST .../streams/pages

Expected

• Background rendering should not block the main event loop, so the API and the import stay responsive. For example, it could yield between pages or run in the worker thread.
• Alternatively, an option to defer re-rendering until the import has finished.

Notes / workarounds tried

• Raising liveness/readiness failureThreshold (180) and timeoutSeconds (10) stops the pod from being killed or removed from the Service. It does not prevent the stall.
• More CPU would not help: the process is single-threaded and already uses a full core.

[NGPixel]

The render job isn't the issue, it's already a separate headless chromium process. It can't block node's main process. The page appearing in the logs just happens to be the one being rendered at that time.

Do you have pages with base64-encoded images or very large tables?

[HermessNRJ]

Indeed, I tried several imports, even with rendering disabled, and it still kept crashing around the thousandth page because of a timeout caused by the regex being too slow. I converted the base64 images into files, and it’s working properly now.

[NGPixel]

Thanks for confirming. I pushed a fix to better handle the regex which will land in the next release.