fix(up): don't fail CI mode when log streaming can't connect - #1100
Merged
Conversation
'railway up --ci' exits 1 when the build-log WebSocket subscription fails to connect, reporting a build failure for deploys that are still running and often succeed. The subscription handshake had a 1-second budget (DNS + TCP + TLS + upgrade), which a CPU-starved machine — a loaded CI runner, or a VM building at full tilt — misses on every one of the 12 retries; the backoff schedule sums to ~66s, matching the failures observed in production to the second. Two changes: - give the WS upgrade a 10s budget instead of 1s - in CI mode, treat a dead log stream as a lost picture, not a lost deploy: fall back to polling the deployment status over plain HTTP (which works whenever the upload could happen at all) and exit with the real verdict. The status subscription's connect failure gets the same fallback. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
coffee-cup
approved these changes
Aug 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR - Dev New holds the CLI up flow in a long session so bumping up WSS timeout.
Problem
railway up --cireports build failure (exit 1) when the build-log WebSocket subscription can't connect — even though the deploy is running and frequently succeeds. Hit four times today by dev.new publishes (which driveup --ciinside the VM); every failed publish had a deployment that builtSUCCESSserver-side. One first-publish victim ended up with a healthy deploy and no domain, because the caller trusts the exit code and skipped its post-deploy steps.The fingerprint: failures at 65.8s, 66.6s, 67.2s, 67.8s. That's exactly
LOGS_RETRY_CONFIGexhausting — 12 attempts, backoff 1s ×1.5 capped at 8s sums to ~61s of sleeps plus connect overhead ≈ 66s.Root cause: the WS upgrade request has a 1-second total timeout (DNS + TCP + TLS + 101 upgrade). On a CPU-starved machine — a loaded CI runner, or a Railway VM with a build pegging its vCPUs (the dev.new case: the coding agent was mid-build) — the handshake misses 1s on every retry, while plain HTTP POSTs (the upload itself!) succeed fine. Network was ruled out: 75ms round trip from the affected host to backboard.
Fix
subscription.rs: 10s handshake budget instead of 1s.up.rsCI mode: a dead log stream is a lost picture, not a lost deploy. Instead ofexit(1), fall back to polling the deployment status over plain HTTP every 5s (newDeploymentStatusquery) and exit with the real verdict, mirroring the status subscription's behavior (Deploy complete/Deploy failed/Deploy crashed, same JSON shapes). The deployment-status subscription's connect failure gets the same fallback instead of?-ing out of a deploy that's already running.Non-CI behavior unchanged; detach unchanged.
Testing
cargo build+cargo test(113 passing),cargo fmt🤖 Generated with Claude Code