Bug: render IS NULL in DB causes silent HTTP 500 with no recovery path for viewers

[ferr079]

Summary

When a page row has render IS NULL in the database (or an empty string), opening that page returns a silent HTTP 500 "Error | Wiki.js" with no actionable message. The root cause is a thrown error in server/models/pages.js, but the error text never reaches the viewer, and non-admin users have no recovery path.

Affected versions

• Reproduced on: Wiki.js 2.5.312 (Node 22.22.2, PostgreSQL 17, Debian 13)
• Still present on main: confirmed via server/models/pages.js#L959-L965 (same logic)

Steps to reproduce

1. Pick any existing page (e.g. id=31, path services/wazuh).
2. Set its render column to NULL directly in the database — this also happens organically after a failed render job, a manual markdown update bypassing the API, or an admin trying to force a re-render:

   UPDATE pages SET render = NULL WHERE id = 31;

3. Request the page via HTTP:

   curl -sk -o /dev/null -w "%{http_code}\n" https://wiki.example.internal/fr/services/wazuh
   # → 500

4. Output in the browser: generic "Error | Wiki.js" page. No admin banner, no hint to edit-and-save, no stack trace in UI.

Expected behavior

One of the following would be reasonable:

• A. Regenerate on demand — the GraphQL mutation pages.render(id) already exists to regenerate render from content. Calling that logic inline when page.render is falsy would self-heal the page on next view.
• B. Surface the actionable error — the error string "Page has no rendered version. Looks like the Last page render failed. Try to edit the page and save it again." is already defined but swallowed by the generic 500 handler. Rendering it in the error.pug view would at least tell editors what to do.
• C. Background re-render — enqueue a render job and return a "Page is being regenerated, try again shortly" 503 with Retry-After.

Actual behavior

getPage() throws and the exception bubbles to the express error handler, which serves a generic "Error | Wiki.js" 500 page. There is no log line pointing to the page ID either (the Wiki.js journald output I captured only shows the generic stack trace line, not the user-facing message).

Root cause

server/models/pages.js#L952-L969:

static async getPage(opts) {
  // -> Get from cache first
  let page = await WIKI.models.pages.getPageFromCache(opts)
  if (!page) {
    // -> Get from DB
    page = await WIKI.models.pages.getPageFromDb(opts)
    if (page) {
      if (page.render) {
        // -> Save render to cache
        await WIKI.models.pages.savePageToCache(page)
      } else {
        // -> No render? Last page render failed...
        throw new Error('Page has no rendered version. Looks like the Last page render failed. Try to edit the page and save it again.')
      }
    }
  }
  return page
}

The page record is valid (content intact, metadata intact), only render is missing. Throwing here is consistent with the comment but the thrown message is never shown to the viewer.

Suggested fix

Preferred: call the existing render pipeline when render is falsy instead of throwing, so the view endpoint self-heals:

if (page) {
  if (!page.render) {
    // -> Regenerate on demand instead of throwing
    await WIKI.models.pages.render({ id: page.id })
    page = await WIKI.models.pages.getPageFromDb(opts) // reload with fresh render
  }
  if (page.render) {
    await WIKI.models.pages.savePageToCache(page)
  }
}

At minimum, catch the error in server/controllers/common.js (the /page view handler around lines 484-560) and render error.pug with the actionable message rather than returning a generic 500.

Why it matters

This failure mode is not theoretical — it happens in several real scenarios:

• Admins force-clearing the render cache (a legitimate workflow when fixing corrupted HTML).
• Failed render jobs that leave the DB in an inconsistent state.
• Git-sync imports that write content without a render pass.
• Third-party automation that writes to content column directly.

Each of these turns into an opaque 500 for end-users until an admin manually opens and re-saves the page through the editor. With 50+ pages in a typical wiki, that regression is silent and hard to spot.

Happy to prepare a PR if the approach (A, B, or C) is agreed on.