a month ago
Hi Railway support,
I'm experiencing a persistent build failure on one of my services (worker) that has been failing for the past several hours with the same error:
Error: Failed to read app source directory
Caused by: Not a directory (os error 20)
nixpacks exited with an error
Project ID: e884e036-253a-4cdf-9316-922e4bd3a57b
Service ID: 48c8767e-6d61-4833-a7f7-7e2ebe97d4fe
The issue started after I updated some environment variables and triggered a new deploy. Every deploy attempt since then — including Redeploy from a previously successful deployment — fails with the same error at the same snapshot hash:
sha256:1f4df073bc56719b30e5b23e18b08215f69d033a4cd713fb7bcb4f2734780118
It appears Railway is fetching a cached snapshot that is corrupt or points to a non-directory path. The build always routes to the same Metal builder (production-builderv3-us-west1-s6fq) and fails within seconds.
I have tried:
- Multiple railway up deploys with code changes
- Empty commits to bust the snapshot cache
- Redeploying from a previously successful deployment
- Adding a .railwayignore file
Nothing changes the snapshot hash being fetched. The service is currently running on an older deployment, but I cannot deploy any updates.
Could you please clear the snapshot cache for this service, or investigate what is causing this?
Thank you
1 Replies
Status changed to Awaiting Railway Response Railway • 28 days ago
Status changed to Open Railway • 28 days ago
a month ago
cached snapshot on metal builder production-builderv3-us-west1-s6fq is railway-side — the cache key is what they captured server-side, not what you push, which is why empty commits and .railwayignore don't change the hash you keep getting.
tag @brody with project e884e036-253a-4cdf-9316-922e4bd3a57b, service 48c8767e-6d61-4833-a7f7-7e2ebe97d4fe, and the snapshot sha sha256:1f4df073bc56719b30e5b23e18b08215f69d033a4cd713fb7bcb4f2734780118. he can clear the entry on that builder.
one workaround worth trying while waiting: rename the service in settings. railway sometimes treats a rename as a new deploy target and skips the cached snapshot pointer. low effort, occasionally unblocks. otherwise it's the cache clear.