Builds failing 100% of the time — "failed to fetch snapshot" across 4 different builder machines, source unpacks fine
mcfa-ngoodall
PROOP

19 days ago

Project: mcfa-pipeline (Project ID 7e6d5754-8e0c-4303-9b1f-a0e7c1a21a08, Environment ID 975bfa14-89ad-43d2-a2ea-d796b21984bb), service webapp.

Every build attempt for commit 7874583c218ba78421aa4a8d8a054a7ba0fcd114 (branch main) has failed, 6/6 attempts, across at least 4 different Metal builders: builder-vhazis, builder-malfmm, builder-fstdwd, builder-zcsuib.

The original, ordinary push-triggered build (deployment 5c729d7a-560e-4100-a6bd-cb3b443de914, not a manual redeploy, normal build cache) shows this in the build log:

19:56:30.246 scheduling build on Metal builder "builder-vhazis"

19:56:32.130 unpacking archive — complete, 59,453,440 bytes, 186ms

          (nothing further logged; deployment eventually marked FAILED)

So the source snapshot uploads and unpacks cleanly and fast — the failure is downstream of that, before our Dockerfile build even starts producing output. Five subsequent manual redeploys (skipBuildCache: true) all failed faster and more visibly, repeating failed to fetch snapshot several times per builder before Railway rotated to the next one — same outcome every time.

This doesn't look like anything in our repd there; prior deploys of the same servicesucceeded days earlier), and doesn't look like a GitHub-connection/auth problem specifically, since the source

transfer itself succeeds.

Could someone take a look at the builder-sd7a-560e-4100-a6bd-cb3b443de914 and let usknow what's actually failing after archive unpack? Happy to provide more deployment IDs if useful — we have 6

total from today.

Solved

1 Replies

Status changed to Awaiting Railway Response Railway • 19 days ago


mcfa-ngoodall
PROOP

19 days ago

No need to reply. Issue resolved. Detached and reattached the github repository.


Status changed to Solved Railway • 19 days ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...