Any change anywhere in the repo invalidates torrential-build's
`COPY . .` (and therefore the cargo RUN layer after it) on every single
build, so without a persistent cache every build re-downloads and
recompiles every crate from zero regardless of whether torrential/
itself changed -- the ~50 minutes of crates.io traffic that motivated
the CARGO_NET_RETRY/CARGO_HTTP_LOW_SPEED_LIMIT hardening two commits
back gets paid again on every future commit to unrelated files (like
the previous commit's one-line server/ fix).
--mount=type=cache on the cargo registry and target/ dirs persists them
in the buildx cache store instead, independent of layer invalidation.
Cache mounts are NOT part of the final layer filesystem, so the built
binary is `cp`'d out to a stable path (/build/torrential-bin) before the
RUN ends; the run-system stage's COPY --from reads that stable path
instead of target/release/torrential directly.
sharing=locked because the capped builder can be asked to run more than
one image build at a time.
A capped from-source build on .88 got ~50 minutes into the torrential
Rust stage (all deps downloading fine) before one crates.io transfer
stalled below curl's default low-speed floor (10 bytes/s over 30s) long
enough to exhaust CARGO_NET_RETRY's default 3 attempts and hard-fail the
whole build (`failed to download from .../libc/0.2.178/download`, exit
101) -- losing all that download progress since cargo has no persistent
registry cache across a failed RUN layer.
Lower CARGO_HTTP_LOW_SPEED_LIMIT to 1 byte/s (a live-but-slow transfer on
a throttled host shouldn't read as dead), extend the low-speed timeout
and overall HTTP timeout, raise CARGO_NET_RETRY to 10, and disable HTTP/2
multiplexing (single-stream is more resilient to a lossy/bursty link than
multiplexed streams fighting over the same bandwidth).
Third piece of the memory-pressure escape hatch (alongside SKIP_TYPECHECK):
--build-arg CARGO_JOBS=2 bounds cargo's parallel job count for the
torrential build, --build-arg NODE_MAX_OLD_SPACE=4096 bounds Node's
old-space heap for the postinstall/build step. Both default to unset
(no cap, existing behavior unchanged) -- only take effect when explicitly
passed, for building on a host with limited headroom under docker build
--cpus/--memory constraints.
Observed on .88 (2026-08-02): docker build got through deps install,
Prisma generate, and the client bundle fine, then got OOM-killed (exit 143)
during vue-tsc's full-project typecheck -- the host had ~600Mi free and a
fully-exhausted 2GB swap at the time (osrm-routed alone holds ~47GB RSS on
that shared box). This isn't a code problem; it's the single most
memory-hungry step of `nuxt build` landing on an already-saturated host.
--build-arg SKIP_TYPECHECK=true (env NUXT_BUILD_SKIP_TYPECHECK) skips it.
Off by default -- this is a resource-pressure escape hatch for a
contended host, not a reason to stop typechecking; re-run
`pnpm run typecheck` separately once there's headroom.
* Fix Windows and Linux launch
* Add process handler selector, pin Prisma
* Regenerate lcofkiel
* Fix torrential inclusion in image
* Fix layouting
* Implement tree kill for Windows
* Fix server lint
