Builder regression since ~2026-04-17: every new deploy fails because fs.so can't load libuv.so.1

[christophsax]

New deploys have been failing server-side at the "testing if installed package can be loaded" step. The fs R package builds, but its shared library can't resolve libuv.so.1 at load time, so every downstream package that imports fs (directly or transitively) fails to install.

Dep path: shiny → bslib → sass → fs, so every Shiny app on Blockyard is affected, not just blockr boards.

Evidence it's a recent regression:

• App test (Nicolas's demo), bundle built 2026-04-16: running ✅
• App blockyard-empty (mine), bundle attempted 2026-04-20: failed ❌
• Same dependency chain, different outcomes → builder image changed.

Full error from by deploy --wait:

* installing *source* package 'blockr.core' ...
** testing if installed package can be loaded
Error: package or namespace load failed for 'blockr.core':
 .onLoad failed in loadNamespace() for 'blockr.core', details:
  call: dyn.load(file, DLLpath = DLLpath, ...)
  error: unable to load shared object '/store/.builds/b4dfbd3e-7766-42b8-8616-45340ea62e43/fs/libs/fs.so':
  libuv.so.1: cannot open shared object file: No such file or directory
Error: loading failed
ERROR: loading failed

Suggested fix: add libuv1 to the builder image (and/or the base image replacement mentioned in #191):

RUN apt-get update && apt-get install -y libuv1

Happy to retest once pushed.

[nbenn]

Confirmed by capturing worker stderr in CI run 24762380860 (and the prior 24730210973, where the unmodified worker fails identically):

Error: .onLoad failed in loadNamespace() for 'blockr.core', details:
  call: dyn.load(file, DLLpath = DLLpath, ...)
  error: unable to load shared object '/blockyard-lib-store/fs/libs/fs.so':
  libuv.so.1: cannot open shared object file: No such file or directory
Execution halted

Root cause is libuv.so.1 missing from the worker image. Affected scopes:

• Process backend — workers run inside docker/server-process.Dockerfile / server-everything.Dockerfile. We control these; the curated apt list at server-process.Dockerfile:89 has cairo/curl/icu/mariadb/pq/ssl/xml/zstd but no libuv1. Adding it there fixes every Process-backend operator with no further action.
• Docker backend — workers run in whatever image [docker].image points at. Examples and docs default to ghcr.io/rocker-org/r-ver:4.4.3 upstream, which doesn't include libuv1. Without a published blockyard-worker image, every Docker-backend operator has to roll their own to work around this.

Fix in flight as part of #270 (along with the cold-start race the symptoms in #269 surfaced — the autoscaler/health-poller were evicting workers mid-spawn before the libuv error could even surface).

[christophsax]

Re-surfacing this one, because a build-time sibling of the original bug is back — same package (fs), same library (libuv), but a different stage and a different missing apt package.

To recap the distinction:

• Builder regression since ~2026-04-17: every new deploy fails because fs.so can't load libuv.so.1 #264 (this issue, fixed): fs.so built fine, then failed to load at runtime — libuv.so.1: cannot open shared object file. Fix was adding the runtime lib libuv1 to the worker image (it's there now: docker/worker.Dockerfile comments it as "required by fs (Builder regression since ~2026-04-17: every new deploy fails because fs.so can't load libuv.so.1 #264)"). ✅
• Worker image lacks toolchain — can't deploy apps with GitHub-only deps that have nested Remotes #367 / fix(process): build pure-R source pkgs on toolchain-free worker #374 (fixed): pak aborted early on the toolchain-free image for pure-R source deps. Fixed — in my build below, cli/digest/sass/etc. all compile fine. ✅
• Now: fs fails to compile at the configure step — uv.h: No such file or directory. The build image is missing the -dev headers, i.e. libuv1-dev. This is the build-time counterpart of what Builder regression since ~2026-04-17: every new deploy fails because fs.so can't load libuv.so.1 #264 added to the runtime image. ❌

Repro

Pure-CRAN bundle, no GitHub deps (so unrelated to #367/#374), by v0.0.4 (current latest):

# app.R
library(blockr.dag); library(blockr.core); library(blockr.dock)
serve("board", new_dock_board(extensions = new_dag_extension()))

by deploy . --name dock-dag-mini --wait

Fails during dependency restore:

+ fs  2.1.0  [bld][cmp][dl] (1.47 MB) + cmake, make, libuv1-dev
...
✖ Missing 5 system packages. You'll probably need to install them manually:
  * libuv1-dev  - fs
  ...
* installing *source* package 'fs' ...
Configuration failed because libuv was not found. Try installing:
 * deb: libuv1-dev (Debian, Ubuntu, etc)
<stdin>:1:10: fatal error: uv.h: No such file or directory
ERROR: configuration failed for package 'fs'
ERROR: dependency restore failed (exit 1)

(build e88ae8e8-870d-491e-ae48-96ad8446cce7)

Two things worth a look

1. The builder source-compiles everything. All 56/56 resolved packages are marked [bld] (build from source), zero as prebuilt [dl]. This holds even when I force --repositories https://packagemanager.posit.co/cran/__linux__/noble/latest. p3m does serve a noble binary for fs, and docker/worker.Dockerfile describes the intended path as "pak pulls binary R packages from p3m" — so something is keeping the builder on the source path. If binaries were used, fs would never compile and would load fine (runtime already has libuv1 from this issue's fix).

2. Given source builds, the build image needs libuv1-dev. The clean build-time mirror of Builder regression since ~2026-04-17: every new deploy fails because fs.so can't load libuv.so.1 #264's runtime fix:

   RUN apt-get update && apt-get install -y libuv1-dev

   (fs also offers USE_BUNDLED_LIBUV=1 to statically vendor libuv, avoiding both the build-time -dev and the runtime .so — possibly the more robust route, since fs is on the shiny → bslib → sass → fs path of every app here.)

Why CI didn't catch it (and a suggested regression test)

TestHelloShiny already deploys an unpinned basic Shiny app and asserts the build reaches completed, so the shape of a test exists — but it can't catch this:

• It runs only in the merge queue (merge.yml, -tags examples), not in PR ci.yml.
• It pins the builder to ghcr.io/cynkra/blockyard-worker:4.4.3 (which has libuv1 / pulls binaries) — not the prod yard.blockr.cloud builder that source-compiles and lacks libuv1-dev. So the failing config is never exercised.
• The only build-level test (TestBuildE2E_PureRSourceBuildNoToolchain) builds a pure-R package by design; nothing builds a src/ package like fs from source.

Suggestion: add a hello-blockr example (minimal new_dock_board(), pure-CRAN Imports: blockr.core, blockr.dock, blockr.dag) plus a TestHelloBlockr mirroring TestHelloShiny. The key is that it (or TestHelloShiny) run against the prod-equivalent builder image + repos on a cold cache, so fs genuinely source-compiles — otherwise it'll be falsely green like today.

Either fix unblocks the deploy. Happy to retest as soon as something's pushed.