Turning Registration off in the Admin Panel closes the sign-up form. It did not close POST /users/register, which went on creating accounts and handing back login tokens to anyone who asked. A closed instance was open.

The endpoint did have a guard. It asked Accounts._options.forbidClientAccountCreation — and nothing in WeKan ever sets that:

• the only Accounts.config() call, in server/accounts-common.js, sets loginExpirationInDays and nothing else;
• forbidClientAccountCreation: disableRegistration in config/accounts.js is passed to AccountsTemplates.configure(), which is the useraccounts package’s own options object, not Meteor’s Accounts;
• and that disableRegistration is only assigned inside an async Meteor.call('isDisableRegistration', …) callback that fires AFTER configure() has already run — something the file’s own comment records, for a different reason, a few lines above.

Three near-misses, and the condition was always falsy. The guard read as though it worked, which is why it lasted: the name says exactly what it ought to do.

It reads the setting from where the setting lives now - the same getCurrentSetting().disableRegistration === true that the isDisableRegistration Meteor method behind the sign-up form uses, so the form and the API can no longer disagree about whether the door is open. An instance with no Settings document yet still allows registration rather than locking itself out.

Every call that reaches the refusal is recorded and shows in Admin Panel / Problems under authz.register. That is safe to log without drowning the page precisely because there is no legitimate caller: the administrator has turned registration off.

How it was found. #6598 by AhmedLukman changed this guard to read WeKan’s setting, filed against #4774 — a 403 Forbidden from this endpoint that nobody had been able to reproduce, and which this line cannot produce, since it never returned 403 at all. The pull request was closed and the fix written here with a security log entry and the tests the route had never had; the finding is the reporter’s.

Nine tests, four of them negative, on an endpoint that had none: that the setting is read where the Meteor method reads it, that the dead option is not consulted again AND is still set nowhere — so a later change cannot quietly reintroduce two sources of truth that disagree — that an enabled instance still creates the user and answers with its token, and that a missing Settings document does not refuse everybody.

Pressing Cancel on a release-all run did not stop the docker job. It kept going for another twenty minutes and would have pushed a multi-arch image for a release that was being abandoned.

The cause is always(). It is true while a run is CANCELLING, which is exactly why it was chosen in v10.80: a build-mac-x64 queued on a runner label GitHub had retired sat for two hours, was cancelled by hand, and that cancellation SKIPPED charts, ucs and nextcloud — so the Helm chart for an already published WeKan was never pushed, and no error anywhere said why. always() fixed that by ignoring cancellation entirely, and ignoring cancellation is also what disabled the Cancel button on a job that takes hours.

!cancelled() keeps the half that matters — do not skip me because a SIBLING failed — and drops the half that overrides a person. Nine job-level conditions change, across release-all.yml, release-all-missing.yml, Flatpak.yml and AppImage.yml. The 22 step-level if: always() reporting steps do not: those correctly print CANCELLED.

That alone would reopen v10.80, so the other half of the fix is that no job needs a hand cancellation any more. The eight jobs that had no timeout-minutes now have one, and every job in the release workflow is bounded. A stuck job FAILS on its own, and a failure satisfies !cancelled() the same way always() let it through — Cancel is left meaning only what a person meant by it.

v10.93, v10.94 and v10.95 all failed to pack with App exceeds uncompressed size limit of 1 GiB. v10.95 was the first run whose size report worked, and it named the gigabyte: .meteor-spk/bundle 852M plus .meteor-spk/deps 336M, so 1188M against a 1024M ceiling. It also answered the question that report was written to ask — a second meteor-spk pack REUSES the bundle rather than rebuilding it, since the pruned tree stayed pruned across the retry (852M to 833M). So trimming between the two attempts works. 19M was simply never going to close a 165M gap.

Measuring the bundle rather than guessing at it turned up two passengers that are large, unreachable at runtime, and safe to drop:

• uWebSockets.js ships twenty prebuilt binaries — Linux/macOS/Windows times x64/arm64 times four Node ABIs, 121M — and its loader is one line: require('./uws_' + process.platform + '_' + process.arch + '_' + process.versions.modules + '.node'). A machine is one platform running one Node, so the other sixteen files can never be opened by it. Keeping every ABI of the target platform and CPU, so a Node major bump still finds its binary, frees ~93M. The entry below drops the remaining 28M as well.
• Source maps — 4766 files, 188M, over a fifth of the bundle. They exist for a debugger attached to the process. A packed app has none, and a missing .map degrades a stack trace at worst.

releases/bundle-trim.mjs does both, measured at 281 MiB on a real bundle, and the Sandstorm leg runs it beside the existing prune before the retry pack.

An architecture with NO uWebSockets.js prebuild at all — ppc64le, s390x, riscv64, where ddp-server falls back to sockjs — is left completely alone, since deleting the other platforms’ files there would free nothing that matters and could only break the fallback. tests/bundleTrim.test.cjs pins that, the kept ABIs, that a directory merely ending in .map is not a source map, and that the trim runs before the retry pack rather than after it.

Trimming uWebSockets.js down to the prebuilds a grain’s own platform can open freed 93M of its 121M. All of it can go, because a grain loads NONE of it.

The uws transport is OPTIONAL in Meteor 3. ddp-server’s transports/index.js resolves the transport from Meteor.settings.packages['ddp-server'].transport, then DDP_TRANSPORT, then DISABLE_SOCKJS, and DEFAULTS to sockjs — and Npm.require('uWebSockets.js') sits inside the uws transport’s setup(), which runs only for the transport that was actually chosen. sandstorm-pkgdef.capnp sets none of those, and its environ is, by its own comment, the app’s ENTIRE environment. So a grain has been running sockjs all along while carrying 121M of a module it never required.

The pkgdef now PINS DDP_TRANSPORT=sockjs, because the removal should rest on a stated fact rather than on an upstream default staying put, and bundle-trim.mjs takes --transport sockjs, which removes the module whole instead of thinning its prebuilds. 120 MiB measured, 27 MiB more than the platform trim: 1188M becomes ~860M, with over 160M of headroom against the 1 GiB limit.

It is a flag rather than the default because WeKan asks for uws nearly everywhere else — docker-compose, start-wekan.sh, build.sh — and those bundles keep the module, trimmed to the prebuilds their own platform can open.

tests/bundleTrim.test.cjs ties the grain’s pinned transport to the flag the .spk is trimmed with. If those two ever disagreed, the grain would require a module that was left out and fail to boot, which is the one way this can go wrong.

uws is not reliable enough yet to be what a default points at, so nothing WeKan ships selects it any more, and nothing carries the module. Three halves, and each is useless or harmful without the others.

The defaults. Every docker-compose*.yml, start-wekan.sh, start-wekan.bat, build.sh, build.bat, the image’s own ENV block, the snap config and the Sandstorm grain now say sockjs. The commented-out #- DDP_TRANSPORT=uws alternatives beside them are replaced by a note saying why there is no alternative, rather than advertising a value that no longer works.

The bundles. Every place a built bundle is post-processed — the amd64 build, each per-arch rebuild, the repack container, releases/install-node-for-arch.sh and the Dockerfile — now runs bundle-trim.mjs beside the prune it already ran, dropping two things:

• uWebSockets.js, 121 MiB, for the reason in the entry above: a sockjs server never requires the module at all.

• programs/web.browser.legacy, a whole second copy of the client built for browsers without modern JS. 81 MiB measured. Meteor supports running with architectures excluded and says so in webapp’s categorizeRequest(): “If our preferred arch is not available, it’s better to use another client arch that is available than to guarantee the site won’t work”. An old browser is served web.browser; the 404 branch below that is reached only when NO arch matches, which cannot happen while web.browser is there, and autoupdate iterates the programs that actually loaded rather than a fixed list.

  The files are only half of it. The arch is NAMED in programs/server/config.json and star.json, and boot.js builds a dynamic-import root for every name in the first — so the name is removed with the files. Those manifests are mode 444 as Meteor writes them, so they are made writable, rewritten, and set back: failing there would leave the one state that actually breaks a server, files gone and manifests still naming the arch.

The upgrade. An existing docker-compose.yml that says DDP_TRANSPORT=uws would ask the new image for a module it does not have and crash-loop on the require. So the Docker entrypoint and the bundle’s own start-wekan.sh coerce uws back to sockjs before starting anything, and print why — a setting silently ignored is worse than one that fails.

tests/sockjsEverywhere.test.cjs pins the three halves together: a default without the coercion is an upgrade trap, a coercion without the trim is dead weight, and a trim without both is a crash.

The .zip bundles and the Docker image were trimmed with --keep-maps, so only Sandstorm — which had a 1 GiB ceiling to get under — dropped them. Every platform drops them now: 152 MiB per bundle, measured. That is 188 MiB across 4766 files, less the 36 MiB inside web.browser.legacy that the entry above already takes with it.

Nothing on any loading path reads one. A source map translates a position in built code back to the source that produced it — this bundle’s server side is one 117 MiB programs/server/app/app.js, and its 58 MiB app.js.map is what turns app.js:1284531 into a file and a line. The two things that read it are browser devtools, which fetch the .map only while they are open, and Node stack traces through source-map-support. A released bundle has neither attached to it.

The //# sourceMappingURL comments stay behind, and are comments: a missing target means devtools show compiled positions and a server stack trace prints bundle offsets. Debugging a production crash goes back to reproducing it against a development build, which is where the maps still are. The guard pins that no call site keeps them, so one platform cannot quietly drift back to carrying them.