The 10.16-10.21 reports of the ferretdb process pegging ~2 cores for a long time
while node sat idle are the signature of an OpLog tail: Meteor holds a tailable
cursor on local.oplog.rs and FerretDB re-scans it server-side. wekan-control
already defaults to polling-only (it clears MONGO_OPLOG_URL), but ferretdb-control
passed --repl-set-name unconditionally, so FerretDB ALWAYS maintained the capped
OpLog (a second write per mutation, a once-a-minute cleanup, and a tailable cursor
for any stray MONGO_OPLOG_URL to spin on) even when WeKan would not tail it.
Gate --repl-set-name on WEKAN_FERRETDB_OPLOG (default false), matching
wekan-control: in the default polling-only mode FerretDB now runs STANDALONE, with
no OpLog at all; the replica set / OpLog is created only when the admin opts in with
wekan-ferretdb-oplog=true. Opting in is now also cheaper on the FerretDB fork side
(the {ts: {$gt}} tail filter is pushed down and the OpLog Timestamp indexed).
Docs: docs/Features/Admin-Panel/Problems/Migrations.md (FerretDB reactivity mode).
Test: tests/ferretdbOplogGating.test.cjs.
Thanks to xet7 !
docs/Features/Admin-Panel/Problems/README.md describes what Problems offers and
links the detailed pages (existing CPU/RAM/Disk/Recovery plus the new Repairs,
Migrations, Login-Problems and Snap pages). Snap.md documents `snap run
wekan.problems` and its sub-commands (migrations | login | broken-cards | cpu).
Repairs.md / Migrations.md cover the shared board data-repairs and the MongoDB <->
SQLite migration, when they run (board open, server startup, during migration) and
the progress dashboard. Login-Problems.md explains the "Must be logged in" /
"Loading, please wait" causes and fixes, tying them to a saturated ferretdb.
Thanks to xet7 !
During a #6492 data recovery, users should never see a bare connection error.
Two layers now cover the whole window on every FerretDB v1 launch path (snap,
bundled release, Docker):
- In-app spinner (already present): the server clears the RECOVERY_IN_PROGRESS
marker only after a real health probe, so the full-screen overlay behaves
identically everywhere.
- Static bridge page (new, cross-platform): for the brief window while a
just-restored FerretDB comes back up and before Meteor can serve the client,
the launch scripts serve a tiny standalone "recovering your data" page (HTTP
503) on the web port. The snap reuses wekan-maintenance-page.mjs with a
recovery wording; release/Docker serve the portable recovery-bridge.mjs. The
bridge is time-bounded (WEKAN_RECOVERY_BRIDGE_SECONDS, default 20s) so it can
never block WeKan from starting, hands straight over to the in-app spinner, and
is skipped if its page file or the marker is absent.
The launch scripts do NOT delete the marker; only the server does, after
verifying the database serves reads. Tests enforce the bridge is bounded, is
guarded by the page file, and that no script deletes the marker.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
Completes the #6492 data-safety system on the WeKan side (FerretDB detection/repair/cap
landed in the fork):
- Decision brain: models/lib/recoveryPlan.js decideRecovery() picks the least-invasive
recovery when the database is KNOWN corrupt (latest good backup -> previous backup ->
re-migrate from MongoDB -> manual). It never acts on a healthy/unknown database and
never restores a known-bad backup.
- Startup restore/re-migrate: every FerretDB launch path (snap, bundled release, Docker)
can restore the text data BEFORE FerretDB opens the files, on request
(WEKAN_FORCE_RESTORE env or a RESTORE_REQUESTED marker). It copies a known-good backup
INTO the live database (dropping stale WAL side-files); backups are never deleted and
the main wekan.sqlite is only overwritten, never removed. remigrate is delegated to
migration-control. Attachments/avatars on the filesystem are untouched.
- Recovery events: the scripts append JSON lines to recovery-events.jsonl; the server
(server/recovery.js) imports them into the recoveryEvents collection on startup, plus
an admin-only recordRecoveryEvent method.
- Admin Panel / Problems / Recovery: a new admin-only report
(server/publications/recoveryReport.js, wired in adminReports.js/.jade + i18n) lists
the remediation history newest-first, readies up front and fetches directly (no hang).
- Docs: docs/Features/Admin-Panel/Problems/Recovery.md.
Tests (wired into npm run test:unit:node), verified by mirror since there is no Node
runtime here to execute them:
- recoveryPlan.test.cjs (decision logic, positive + negatives)
- recoveryEventsJsonl.test.cjs (parser: skips junk, normalizes severity, never throws)
- recoveryReportQuery.test.cjs (search selector escapes regex metacharacters)
- recoveryReportWiring.test.cjs (report wired; publication/count/method admin-gated)
- ferretdbTextDataBackup.test.cjs extended: restore copies from a backup, is
request-gated, and NEVER deletes the live text data or a backup copy
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
Move CPU-usage design under docs/Features/Admin-Panel/Problems/ and add
RAM-usage and Disk-usage design docs (siblings of CPU-usage): both log
how much RAM+swap / disk is used and record only the START and END of
each sustained high-usage period to Admin Panel / Problems, mirroring the
CPU-usage monitor's shape (hysteresis tracker, event stream, env vars).
Link them from the Admin-Panel index and update the now-automatic card
loading description. Update the CHANGELOG link to the moved CPU-usage.
Lauri Ojansivu