Group cache (WIKI.auth.groups) silently stays empty when the initial reloadGroups() fails at boot — breaks OIDC mapGroups and silently strips users' group memberships

[papso-kirby]

Describe the bug

WIKI.auth.reloadGroups() is called fire-and-forget at startup, without await and without a .catch(), and the function itself has no error handling. If the very first groups query fails for any transient reason at boot (e.g. a Knex: Timeout acquiring a connection. The pool is probably full during the startup burst), the rejection is swallowed and this.groups is never populated. It then stays empty for the entire process lifetime.

This is hard to notice because nothing is logged, and the wiki otherwise boots and runs normally.

Impact (severity: data loss)

With an OpenID Connect strategy that has mapGroups: true, every login runs:

const currentGroups = (await user.$relatedQuery('groups').select('groups.id')).map(g => g.id)
const expectedGroups = Object.values(WIKI.auth.groups).filter(g => groups.includes(g.name)).map(g => g.id)

When WIKI.auth.groups is empty, expectedGroups is always [], so:

• no user is ever granted a group (everyone ends up "unauthorized"), and
• any user who logs in and already had groups gets them unrelate'd — i.e. their existing group memberships are silently deleted from the DB.

So a transient DB hiccup at boot can progressively wipe out group assignments as users log in. In our case the SSO group assignments dropped from 18 → 16 before we noticed.

To Reproduce

1. PostgreSQL backend, OIDC strategy with mapGroups: true.
2. Cause (or hit) a transient DB/connection-pool timeout during the startup window where reloadGroups() runs (right after "HTTP Server: RUNNING").
3. Log in via OIDC.
4. User is "unauthorized" despite a correct groups claim; users with existing
   memberships lose them.

Expected behavior

The group cache must be reliably populated at boot. A transient DB error during startup must not leave the cache permanently empty, and mapGroups must never remove memberships based on an empty/unloaded cache.

Root cause (code, v2.5.311 server/core/auth.js)

init() {
  this.passport = passport
  // ...
  this.reloadGroups()      // no await, no .catch()
  this.reloadApiKeys()
  return this
}

async reloadGroups () {
  const groupsArray = await WIKI.models.groups.query()   // no try/catch
  this.groups = _.keyBy(groupsArray, 'id')
  WIKI.auth.guest.cacheExpiration = DateTime.utc().minus({ days: 1 })
}

A single rejected query here = empty cache for the whole process. The only recovery is something that calls reloadGroups() again at runtime (e.g. saving any group in the admin UI), which masks the problem.

Environment

• Wiki.js: 2.5.311
• DB: PostgreSQL
• Auth: OpenID Connect with mapGroups: true

Suggested fix

1. Make reloadGroups() resilient: wrap in try/catch with a bounded retry, so a transient boot-time DB error doesn't leave the cache empty (and log on final failure instead of swallowing the error).
2. Guard mapGroups against an empty cache: skip the sync (especially the unrelate step) when WIKI.auth.groups is empty, to avoid destructive group removal based on incomplete state.