upd build is finally goes ok but i cant understand what is the main problem if even logs not working correctly

asked claude to add some notes:

Deploy method: railway up --detach (CLI source upload, not GitHub), CLI v5.15.0, upload ~36 MB, from macOS.

For ~1 month: CLI printed Failed to upload code with status code 500 / operation timed out, but the deploy actually completed server-side — the CLI error was cosmetic (failed on response-receipt, not on the deploy itself).

Today it changed: same CLI errors, plus real failures at Initialization › Snapshot code → Failed to create code snapshot.

Notable signal: intermittently the CLI dies with a TLS error cannot decrypt peer's message on the upload connection — looks like an unstable upload transport, not the commit.

Hit rate today ~1 success / 20 attempts; only fix is retrying railway up until a Build Logs: URL is returned.

Hypothesis for staff to check: is the snapshot step failing because the uploaded archive arrives incomplete/corrupt due to the flaky upload connection? The diagnosis blames "your last commit", but the same commit succeeds on retry with no changes — which points to the upload path, not the code.

Hi. Your own notes are pretty close to the answer — the snapshot isn't blaming your commit, it's choking on a truncated upload.

Here's the chain: railway up streams the archive from your machine to Railway's ingest endpoint. If the TLS connection dies mid-transfer (cannot decrypt peer's message is the classic signature of a connection dropped mid-record, often NAT/router/VPN or flaky Wi-Fi), the server can end up with an incomplete archive. The snapshot step then can't extract it and reports "Failed to create code snapshot, review your last commit" — which is misleading wording, because your commit was never the problem. It also explains the 1-in-20 success rate and why retries with zero changes eventually work: you're just re-rolling the dice on the connection.

The 500s from the CLI are the same story — the upload went through (or didn't) but the response never made it back, so the CLI reports a failure that may or may not be real.

A few things that should steady it:

Rule out the local path — try a different network (phone hotspot), disable VPN/proxy, and check macOS power settings aren't napping the connection mid-upload.

Update the CLI — you're on v5.15.0; there have been transport fixes since, so npm i -g @railway/cli and see if the 500-on-response behaviour improves.

Add a retry loop — since retries do land, something like until railway up --detach; do sleep 5; done will push through the flaky windows without babysitting.

Longer term — pushing via GitHub connected deploys sidesteps the whole local-upload path entirely; Railway fetches from the repo server-side, so a flaky home connection can't corrupt anything.

If it's still failing at the snapshot step with a clean network and current CLI, that's worth a Private Thread with the team since you're on Hobby — but based on what you've described, it's the transport, not the commit.