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.