[Fix] Workspace stuck in Booting environment with no failure reason

[roomote-roomote]

Opened on behalf of Daniel Riccio. Follow up by mentioning @roomote-roomote, in the web UI, or in Discord.

What changed

Failed environment boots no longer strand users on Booting environment with only a raw docker run dump.

• Docker spawn failures lead with the real daemon stderr/stdout reason, with Docker -e / --env values redacted in every diagnostic path (including empty-stderr error.message fallback and stderr/stdout blocks)
• Docker failures no longer attach the raw execFile error as cause, and spawn failures are captured/rethrown as sanitized errors so Sentry LinkedErrors cannot store an unredacted AUTH_TOKEN
• Startup UI maps common self-host failures (missing/unauthorized worker image, daemon down, port conflicts, worker timeout, worker fetch failed, missing release archive) to clear guidance while keeping useful details
• Active boot shows Still booting… (elapsed) after 10s
• Docker worker readiness wait is 60s (up from 15s) with clearer timeout messaging
• Rebased onto current develop so cancel/AbortSignal during Docker provision is preserved (abort errors are not reformatted as spawn failures)

Why this change was made

Self-hosted setups often failed behind opaque boot UI while the real cause lived only in host Docker logs (missing roomote-worker image, daemon issues, worker fetch failed). Operators need the actual reason in-product without leaking run auth tokens into the UI or Sentry.

Impact

When boot fails, users see actionable failure copy (and optional details) instead of a raw command. Long boots show elapsed time so the UI feels alive. Secrets in docker -e args are not stored, displayed, or linked into Sentry via error causes. Cancel-while-provisioning behavior from develop remains intact.

Screenshots

Linked work items

Closes #538

[roomote-roomote]

1 issue outstanding. See task

• apps/controller/src/compute-providers/docker-sandbox-security.ts:155-159: reason falls back to the raw execFile error.message without redaction. For a docker exec failure with no stdout/stderr, Node includes the full command there; the worker launch command contains -e AUTH_TOKEN=<run token>, so this stores and displays the token in the task failure. Sanitize that fallback (or route it through sanitizeDockerCommandForDisplay) before persisting it.
• apps/controller/src/compute-providers/docker-sandbox-security.ts:246: The new error wrapper retains the original execFile error as cause, then BaseController passes that error to Sentry. @sentry/node enables LinkedErrors by default, so it serializes the raw cause and stores the unredacted docker exec -e AUTH_TOKEN=... message in Sentry. Capture a sanitized error/cause instead of the raw execFile error.
• apps/web/src/lib/task-run-errors.ts:132-147: A worker-start timeout always includes both the process list and recent Docker logs, but if the logs match a recognized diagnostic (for example fetch failed), extractDockerDiagnosticReason returns that log block and this early return skips the process-list trailer. Preserve both diagnostic trailers so the new timeout diagnostics are not dropped in this common failure case.

_{Reviewed 596d8b8}

[easonLiangWorldedtech]

@roomote-roomote @mrubens Hi! I've been testing this on my self-hosted setup and can confirm it resolves the issue.

Test Results

Environment:

• Version: v0.12.0 (self-host, commit 3e28c5d9)
• Image: roomote-app:local-self-host
• Setup: Docker Compose from source at /tmp/roomote-setup-latest

Before Fix (v0.12.0)

Workspace got stuck in "Booting environment" with no useful error feedback. Screenshot shows the raw failure without explanation.

After Fix (PR #544)

The fix works! The improved error handling now:

• Shows real stderr/stdout reason for Docker spawn failures ✅
• Maps common self-host failures to clear guidance ✅
• Shows "Still booting… (elapsed)" after 10s ✅
• Increased worker readiness wait from 15s to 60s ✅

Additional Finding: CRLF Issue on Windows/MSYS

While testing, I also discovered that several .sh files in the repo have CRLF line endings which cause Docker build failures on Windows:

/sandbox/install-worker.sh: line 2: $'\r': command not found

Files affected (copied into Docker image):

• .docker/run-with-dotenvx.sh
• .docker/app/entrypoint.sh
• .docker/sandbox/install-worker.sh
• .docker/sandbox/install-browser-agent.sh
• scripts/build-worker-release.sh
• apps/preview-proxy/entrypoint.sh

Fix: find . -name '*.sh' -exec sed -i 's/\r$//' {} \; before Docker build.

Summary

✅ PR #544 fix confirmed working for the "Booting environment" stuck issue
⚠️ Separate CRLF issue exists for Windows/MSYS environments (not related to this PR)

Thanks for the quick fix! 🎯

[roomote-roomote]

I saw the mention, but I need your GitHub account linked to Roomote before issue and PR comments can start work here. Link it from Settings -> Linked Accounts and then mention me again.

[daniel-lxs]

Reviewed the full diff plus follow-up commits: abort/cancel passthrough verified against the AbortSignal path, redaction covers argv/cmd/stderr/stdout and the empty-stderr message fallback, error-shape consumers (disk-limit retry, object-not-found detection) still match on the wrapped message, and the timeout display path now preserves the Docker process list. Tests and full CI green.