v9.92 2026-07-15 WeKan ® release

This release fixes the following bugs:

• Snap: WeKan never started on a running MongoDB, looping "MongoDB not ready yet,
  retrying in 5 seconds..." forever, on any server with less than ~34 GB RAM
  (#6454, snap-src/bin/mongodb-control,
  snap-src/bin/migration-control). The WiredTiger cache size was hardcoded to 32 GB.
  On a smaller box (e.g. 8 GB) mongod was OOM-killed seconds after it started — including
  the temporary mongod that mongodb-control starts to initialise the replica set, which
  died before it could be reached, so the replica set was never initiated. The final
  mongod then ran with --replSet rs0 but no config, no PRIMARY was ever elected, and
  since Meteor requires the replica-set primary (change streams), wekan-control waited on
  it forever. Fixes: (1) the cache size is now RAM-aware — ~50 % of (RAM − 1 GB), the
  same formula mongod uses for its own default, capped at 32 GB, min 1 GB, overridable with
  MONGODB_WIREDTIGER_CACHE_GB; (2) the temporary-mongod readiness wait is raised from 30 s
  to 90 s so a large database that needs longer to replay its journal still gets its replica
  set initialised; and (3) the temporary source mongod that the MongoDB → FerretDB migration
  starts to read the data now uses a conservative RAM-aware cache (¼ of (RAM − 1 GB), cap
  8 GB) so it leaves room for the target FerretDB and the importer running alongside it.
  Thanks to xet7.

• Snap: the MongoDB 6/7 → FerretDB importer now resolves the correct driver and matches
  the MongoDB 3.2 importer's safety and dashboard (releases/migrate-mongodb-to-ferretdb.mjs).
  It now (a) resolves the mongodb driver by probing the WeKan bundle and using whichever
  actually works — preferring a v6+ driver that exposes GridFSBucket and speaks OP_MSG,
  because an older v2 driver's OP_QUERY is rejected by FerretDB ("Unsupported OP_QUERY command:
  update"); and (b) gained the same disk-space guard and progress UI as
  migrate-mongo3-to-ferretdb.mjs: it measures the total attachment/avatar size up front and
  stops before extracting if it will not fit, and if space runs out mid-run it stops,
  deletes the partially-migrated files, and reports how much more disk is needed (a full disk
  can corrupt the still-running source MongoDB), shows a live per-file progress bar, and
  translates the dashboard into the browser's language. Thanks to xet7.

• Snap: verified the migration's disk-space guard actually works inside snap confinement
  (snap-src/bin/migrate-mongo3-to-ferretdb.mjs, releases/migrate-mongodb-to-ferretdb.mjs —
  comment/documentation only, no behaviour change). statfs (and statfs64 / fstatfs /
  fstatfs64 / statvfs / fstatvfs) is in snapd's default seccomp allow-list
  (snapcore/snapd → interfaces/seccomp/template.go), and a snap has no per-snap disk quota
  by default, so the migration's free-space check (statfsSync on $SNAP_COMMON/files)
  returns the real free space and its "stop before the disk fills" safety is fully active on
  Snap. quotactl is not allowed, but the migration never calls it; the one case it would
  matter — a snapd storage-quota group (project quotas invisible to statfs) — is still caught
  by the ENOSPC/EDQUOT write-failure fallback. Only Sandstorm grains genuinely lack
  statfs (FUSE does not implement it, quotactl blocked), where the guard already relies on
  that write-failure fallback. Thanks to xet7.

• Snap: after a MongoDB → FerretDB migration, FerretDB never started and WeKan was stuck
  on "MongoDB not ready yet, retrying..." (snap-src/bin/migration-control). The
  wekan.ferretdb service disables itself while database is mongodb; the migration
  then switches the snap with an internal snapctl set database=ferretdb, but an
  internal snapctl set does not re-run the configure hook that flips the two
  database services — so FerretDB was left disabled and MongoDB enabled but stopped,
  leaving WeKan with no database (both bind the same port, so only one runs at a time).
  finish_success now performs the flip itself, exactly as the configure hook's ferretdb
  branch does: enable + start (and restart) wekan.ferretdb, then stop + disable
  wekan.mongodb — using the snap instance name so parallel snaps target their own
  services. Immediate recovery on an already-migrated install — flip the setting so the
  configure hook re-runs and enables + starts FerretDB and stops MongoDB (do not try
  snap start wekan.ferretdb directly; while database is still mongodb, ferretdb-control
  reads the setting and disables itself again — see the next entry):
  sudo snap set wekan database=ferretdb.
  Thanks to xet7.

• Snap: the migration-success marker is now authoritative, so FerretDB starts even if the
  database setting was never flipped (snap-src/bin/ferretdb-control,
  snap-src/bin/mongodb-control, snap-src/bin/wekan-control). Every DB service keyed its
  behaviour off the database setting alone: ferretdb-control logged "database is
  'mongodb', not 'ferretdb'. Disabling ferretdb service." and self-disabled whenever the
  setting still said mongodb — so on an already-migrated install snap start wekan.ferretdb started and then immediately stopped itself, unfixable by hand without
  first setting database=ferretdb. Now the marker
  $SNAP_COMMON/.migration-to-ferretdb-done overrides the setting: when present,
  ferretdb-control repairs database=ferretdb and keeps running instead of self-disabling;
  mongodb-control disables itself (before the migration-pending check, so a finished
  migration is never re-attempted); and wekan-control forces ferretdb and brings the
  service up. WeKan thus recovers on its own after a migration whose setting flip was lost.
  Thanks to xet7.

• Snap: WeKan now starts its database itself on startup instead of waiting forever for a
  stopped one (snap-src/bin/wekan-control). Previously the wekan.wekan service only
  waited for whichever database database pointed at (FerretDB not ready yet… /
  MongoDB not ready yet…) and never started a DB service, so if both wekan.ferretdb
  and wekan.mongodb were stopped/disabled WeKan hung indefinitely. Now, before waiting, it
  enables + starts whichever DB service is configured (snapctl start --enable = snap enable + snap start, targeting the snap instance name so parallel snaps hit their
  own services). Thanks to xet7.

• Snap: WeKan never starts an EMPTY FerretDB while data still lives in MongoDB
  (snap-src/bin/wekan-control). On startup WeKan now checks what data actually exists on
  disk — the FerretDB SQLite dir ($SNAP_COMMON/files/db) and the MongoDB WiredTiger data
  ($SNAP_COMMON) — instead of trusting the database setting alone. If database=ferretdb
  was selected (or forced) but the migration never ran, so the SQLite database is empty while
  MongoDB still holds the data, WeKan reverts to database=mongodb and prints how to run
  the migration, rather than starting an empty FerretDB that would look like all data was
  lost. Thanks to xet7.

Thanks to above GitHub users for their contributions and translators for their translations.