v9.99 2026-07-17 WeKan ® release

This release fixes the following BUG:

• LDAP connection leak: WeKan exhausted the directory server with "too many open connections"
  (#6467, #6469).
  Operators reported that after an update WeKan "dies really quickly", that restarting the server did not
  help, and that it "kills our openldap server with too many open connections"; others saw logins hang for
  minutes and then fail with "Must be logged in". Root cause: every LDAP login attempt
  (packages/wekan-ldap/server/loginHandler.js) and every background sync run
  (packages/wekan-ldap/server/sync.js) created a fresh new LDAP() and called connect(), but the code
  never called disconnect() on any path — success, failure, or fallback. Each login attempt (including
  every failed one) and each background-sync tick (every minute by default) therefore leaked one socket to
  the LDAP/AD server. Over time this grew without bound until the directory server hit its per-client
  connection limit and started refusing connections, which took it — and, with it, every WeKan login — down.
  • Fixed by guaranteeing the connection is always released:
    • A small shared helper packages/wekan-ldap/server/connectionGuard.js (runWithLdapDisconnect(ldap, fn))
      runs the work and disconnect()s in a finally, on every exit path. The disconnect is best-effort and
      never masks the original result or error.
    • The LDAP login handler now runs its whole flow through runWithLdapDisconnect, so connect() is always
      paired with a disconnect() — on a successful login, a thrown Meteor.Error, or a fallback to the
      default account system.
    • The background sync() releases its connection in a finally, and importNewUsers() disconnects only
      the connection it opened itself (never a connection borrowed from sync()).
    • The admin ldap_test_connection method (packages/wekan-ldap/server/testConnection.js), which had the
      same leak, now disconnects on both the success and failure paths, so repeated "Test Connection" clicks
      no longer leak either.
    • LDAP.disconnect() is now a safe no-op when connect() was never reached, so cleanup can never throw.
  • Tests (tests/ldapConnectionRelease.test.cjs, added to test:unit:node): behavioural coverage of the
    guard (disconnects after success and returns the result; disconnects exactly once; disconnects and
    re-throws when the work throws — the failed-login path that exhausted OpenLDAP), negative cases (a failing
    disconnect never turns a success into a failure nor hides the real error; a missing/null ldap is
    tolerated), plus source-level guards that the leak-prone call sites actually route through the guard and
    that connect() lives inside the guarded region.
  • Thanks to the reporting operators and xet7 (fix).

This release also updates the bundled FerretDB (see the fork's own CHANGELOG Upcoming): the SQLite backend
connection pool no longer caps MaxOpenConns at 16, which had starved WeKan's cursor-heavy load and made
boards take minutes to load and logins fail with "Must be logged in" (#6467,
#6469).

• Snap: FerretDB never becoming ready made WeKan hang with no web port and no explanation
  (#6476). With database=ferretdb, snap-src/bin/wekan-control
  waits for FerretDB to accept connections before starting WeKan — WeKan does not open its HTTP port until
  the database answers. That wait loop had no timeout and no diagnostics: if FerretDB never started
  listening (a crashed or CPU/architecture-incompatible per-arch binary, a locked or corrupt SQLite database,
  or the FerretDB service left disabled by a failed migration hand-off), WeKan blocked there forever. The
  service showed as active, but the port never opened and the only symptom was a silent
  FerretDB not ready yet, retrying in 5 seconds repeating — exactly what #6476 reported (Apache proxy could
  not connect to port 3333). The reporter's wekan.log stopped right after the startup env dump, confirming
  control never reached node main.js.
  • Fixed by mirroring the MongoDB branch: after WEKAN_DB_WAIT_TIMEOUT seconds (default 120,
    overridable) the FerretDB wait loop now prints an actionable hint once and keeps retrying — pointing to
    snap logs <snap>.ferretdb for the real error, naming the SQLite directory to check for locks/corruption,
    the arch-mismatch (exec format error) case, the snap start --enable <snap>.ferretdb recovery, and the
    snap set <snap> database=mongodb fallback to keep working meanwhile. This turns "port never opens, no
    clue why" into a clear message. Regression test: tests/ferretdbWaitTimeout.test.cjs, including a negative
    guard that the FerretDB wait is not a silent unbounded loop again.
  • This is a robustness/diagnostics fix; the underlying reason FerretDB was not accepting connections is
    environment-specific and lives in the FerretDB service log.
  • Thanks to uusijani (report) and xet7 (fix).

Thanks to above for their contributions.