Bug: page update mutation without tags half-applies the update — content is saved, render/search/storage are skipped, then the API reports failure

[ferr079]

Summary

Calling the GraphQL pages.update mutation without the optional tags argument crashes mid-pipeline with:

Cannot read properties of undefined (reading 'map')

The schema declares tags: [String] as optional on update (page.graphql), so this is a legal call per the API contract — but the implementation throws. The error itself is old news (#2702, closed in 2021 with a "pass tags" workaround). What I haven't seen reported is the dangerous part:

The update is half-applied. The raw content is committed to the DB before the crash, but everything after the crash point is skipped. The API then tells the client the update failed.

Observed consequences

When the mutation is called without tags:

1. ✅ content, title, description, etc. are saved (the patch() runs first)
2. ❌ renderPage is skipped → the page serves the stale rendered HTML (viewers don't see the new content)
3. ❌ Search index update is skipped → search results stale
4. ❌ Storage sync (e.g. Git) is skipped → external storage diverges from the DB
5. ❌ The client receives { succeeded: false, message: "Cannot read properties of undefined (reading 'map')" }

Point 5 is the trap for API automation: a client that trusts the response and retries the update (e.g. a script doing read-modify-write with appends) will apply its change twice, because the first attempt actually persisted. That's how I found this — an automation almost double-appended content after treating the response as a clean failure.

This also leaves the page in the same family of inconsistent states as #7986 (render out of sync with content): the page pipeline is not atomic, and a mid-pipeline throw strands the page halfway.

Minimal reproduction

mutation {
  pages {
    update(id: 121, content: "updated content", isPublished: true) {
      responseResult { succeeded message }
    }
  }
}

→ Response: {"succeeded": false, "message": "Cannot read properties of undefined (reading 'map')"}
→ DB check: content was updated anyway; render still holds the previous version.

Reproduced on 2.5.x (PostgreSQL). The code path is unchanged on main as of 6f042e9.

Root cause

server/models/pages.js — updatePage:

// -> Update page
await WIKI.models.pages.query().patch({ ... content: opts.content ... })  // L426 — commits first
let page = await WIKI.models.pages.getPageFromDb(ogPage.id)

// -> Save Tags
await WIKI.models.tags.associateTags({ tags: opts.tags, page })           // L443 — unguarded

server/models/tags.js — associateTags:

tags = _.uniq(tags.map(t => _.trim(t).toLowerCase()))  // L58 — TypeError when tags is undefined

Interestingly, createPage does guard this same call (pages.js#L328):

if (opts.tags && opts.tags.length > 0) {
  await WIKI.models.tags.associateTags({ tags: opts.tags, page })
}

updatePage just misses the equivalent guard.

Suggested fix

Mirror the createPage guard in updatePage, with update semantics:

// -> Save Tags
if (opts.tags) {
  await WIKI.models.tags.associateTags({ tags: opts.tags, page })
}

• tags omitted/undefined → leave existing tags untouched (consistent with how other optional fields behave on update)
• tags: [] explicitly passed → associateTags already handles unrelating all tags

A defensive tags = tags || [] at the top of associateTags would also protect any other caller. Longer term, wrapping the update pipeline (patch → tags → render → search → storage) in a transaction would prevent this entire class of half-applied updates — but the one-line guard fixes the reachable crash today.

Workaround for API users

Always pass tags explicitly on update (fetch the current tags first via pages.single(id) { tags { tag } } and echo them back). And do not trust succeeded: false to mean nothing was written — verify before retrying.