From #6583: “The migration and the update to 10.83 startet at 11.08.2026 at 6:35 pm and migration failed. Now we just see the old data from a migration we did in july 2026. … Which steps exactly could we do, to restore the database with our most recent data?”

Everything needed to answer that already existed — db-eval evidence, database-choose.mjs, database-merge-missing.mjs, database-autopick — and none of it was a command anybody could run. snap run wekan.problems answered “No problems detected”, which is true of the things it checks and no help at all here.

sudo snap run wekan.database-compare    # what does each copy hold?
sudo snap run wekan.database-merge      # bring the missing documents across

compare starts each database on a temporary port, counts its documents and finds the newest moment its data carries, and prints both sides — the running WeKan is not disturbed, and nothing is written. A file timestamp cannot answer this question: starting a database moves its files, and a file written a minute ago may hold nothing anybody typed.

merge inserts the documents that exist in the MongoDB copy and not in the FerretDB one. It overwrites nothing, deletes nothing, and reads the MongoDB files only — so it is safe to run without first knowing which copy is “right”. That is WeKan’s own design doing the work: the history is append-only, so merging can only ADD to what a card shows, and the work that was stranded becomes readable in that card’s History. What it does not do is reconcile two edits of the same card; the served copy’s version stands, and the other stays where it is. It asks for a copy of $SNAP_COMMON first, with the command, and takes --dry-run.

The removed snap run wekan.database switch is gone from the core26 snapcraft file as well, where it had been left behind.

Reported by email: “Previously archived cards (some several years old) have reappeared. These cards have incorrectly been placed in the top swimlane.”

Archiving a swimlane is how a whole swimlane is put away: its cards stay where they are, archived: false, out of sight because the swimlane is. The schema upgrade’s swimlane rescue read that as breakage and moved every such card to the board’s first VISIBLE swimlane — so work anybody had ever archived that way came back, years later, at the top of the board.

A card is orphaned when its swimlane does not exist, or belongs to another board. That is #1959, and it is still rescued. The other issue the sweep cited, #1971, is about cards added in List view landing in an archived swimlane — and that is fixed where cards are created, by getDefaultSwimline() picking a non-archived swimlane. It never needed a sweep over data somebody archived on purpose.

The two guards that pinned the sweep now pin the opposite, each carrying the reason, and a board whose every swimlane is archived is left exactly as it is.

Reported by email, with a screenshot of the Ändra bevaka popup: “Silent does not respond. If we try to change it does not change. Nothing happens.”

Driven against a running WeKan, the popup works for a board member — the level is written, the check mark moves, the popup closes — and does nothing at all for anybody else:

login as non-member admin: ok
watch -> ERROR error-board-notAMember

A board is shared four ways: membership, an organisation, a team, and (since #5850) an email domain. Only the first puts anybody in members, and the watch method asked hasMember(). Everyone reaching a board through an org, a team or a domain could open it, see the button, and be refused the moment they used it. It asks whether the user may see the board now, through the same selectors the publications use — so a watch can never be granted where the board is not visible, and a revoked share still is not.

The other half is why nobody could tell: the popup closed on success and did nothing otherwise, so a refusal was indistinguishable from a dead button. It reports the reason now — the watch feature being off in the Admin Panel, or the board not being visible — and error-watch-disabled, thrown since #5820 but never translated, exists as a string.

#6589: a .drawio upload was stored and displayed as .bin, could not be opened, and could not be renamed back either — renameAttachment threw ENOENT. Two faults.

The name. A browser sends application/octet-stream for a type it does not know, and the upload-time “correct the extension to the type” step took that literally: mime.extension('application/octet-stream') is bin, so sso-proconnect-keycloak.drawio became …drawio.bin. Every unrecognised format — .drawio, .kdbx, .ova, anything new — went the same way. An uninformative type now yields no extension at all, while a type that does say something still corrects the name, which is what that step is for.

The rename. The recorded versions[].path and the file on disk had diverged, and rename used the recorded path alone:

Error: ENOENT: no such file or directory, rename
  '/data/files/attachments/6a7d66369c6aee799e857d36.drawio' -> ...

while the READER already searched every layout WeKan has used and found the file. That search is a method now, and reading, renaming and deleting all use it — so an attachment that can be read can also be repaired. When there really is no file, the error names the attachment instead of a path nobody recognises.

#6590: “A board gets stuck indefinitely on the loading animation (three dots) for all users”, traced to one card whose description and checklist item held onenote:///path/to/file.one#section-id={GUID}.

It is #6588 from the other end — the same this.__schemas__[...].validate is not a function out of linkify-it 6, reported as a board nobody could open rather than a card nobody could open — and it was fixed on 2026-08-12. The regression test now renders that exact string, in a description and in a checklist item, and pins that the {GUID} stays text rather than being swallowed into a link.

#6591: “Board Settings -> Export board -> export/Excel didn’t work”. Reproduced against a running WeKan — CSV and JSON of the same board answered 200, and Excel never answered at all:

csv:   HTTP 200 4758b
json:  HTTP 200 4491b
excel: Operation timed out after 30002 ms with 0 bytes received

with nothing in the server log. Two faults, either of which hangs the browser on its own.

The zip. exceljs 4.7.3’s streaming writer calls archiver the way archiver 7 was called — Archiver('zip', opts) — and WeKan moved to archiver 8 for the low-memory backup zips. archiver 8 is ESM and exports classes, so that is TypeError: Archiver is not a function, and the export has been broken since the bump. Supplying the missing factory does not rescue it either: archiver 8’s readable-stream then refuses the objects exceljs appends. So the export asks what archiver exports and, when it cannot stream, it uses a buffered writer with the same API — the path this export used before it was made streaming. Bounded memory is what is lost, not the export.

The silence. The route called exporterExcel.build(res) without awaiting it, so the rejection went nowhere: no 500, no log line, and a response that was never written or ended. Every sibling route awaits; this one did not. It does now, and a failure answers 500 with the reason.

From #6585, a log that says everything except the useful part:

[migration] mongod 7 could not open the data; trying the bundled mongod 5.0 ...
[migration] mongod 7 could not open the data; trying the bundled mongod 4.2 ...
[migration] The database files were made by an older MongoDB
            (MongoDB 4.2 or earlier can still read them).

Every reader was tried, each of them said something, none of it was shown — and the conclusion recommends the version that had just failed. mongod 7 names the version that can open the FORMAT; it cannot know the files are also damaged, or left locked by an unclean shutdown.

So each reader now prints its own last words when it does not open the data, the “trying the bundled X” lines name the reader being tried instead of blaming mongod 7 for all of them, and when mongod 7 asks for a version this snap carries, the report says it was tried too and that --repair on a copy is the usual next step.

And the other half of that report — “If you need us to run some external tools, like an old mongodb, it would be good to provide a source for them” — the log and the explanatory page now link mongodb.com’s download page and fastdl.mongodb.org, name the docker run mongo:<version> one-liner, and spell out mongod --dbpath / mongodump on a copy, never the original.

The v10.89 run published the armhf, ppc64el and s390x snaps and then failed on the next line:

Revision 3661 created for 'wekan' and released to
  'beta', 'candidate', 'edge', and 'stable'
no git remotes found
Error: Process completed with exit code 1

Those jobs flatten history so the Launchpad push stays small, and the git remote goes with it — so gh had nothing to infer the repository from. The snap was in the store and not on the release, which reads like a failed build.

Every gh release upload, view and edit in every workflow now names the repository, so the call does not depend on what the checkout looks like, and a bare one fails the guard.

v10.89’s riscv64 leg ran five hours and fifty minutes — its cap — with Launchpad still printing Building: riscv64, and the run showed CANCELLED and nothing else. What is true at that moment is worth saying: the Launchpad build is not cancelled with the job, it keeps its name, and re-running the job reconnects to the same build and downloads the snap rather than starting another one.

The cap is now 360 minutes, the maximum a hosted runner allows, and a cancelled job prints that explanation plus any Launchpad URL its logs carry.