Persistent build failure — corrupted cache-key reference, single service/environment, not commit-related
itrexru
PROOP

a month ago

Project: b5845153-7aa5-4f4c-bf2b-8c8cf54ce1e6 Environment: production (be48a64a-161d-4408-96ac-4a1ddbbecccc) Service: edi-site (ccbb91a9-4ba7-48c1-a526-df168d001477) Builder: Metal builder "builder-fmoiwh", Railpack v0.38.0, image mise-2026.8.13

Every build of this service in this environment fails at the context-copy stage with:

failed to solve: failed to compute cache key: failed to calculate checksum of ref k7wj9be0tbuc41h0mtq6wg52k::: "/apps/copilot/prisma": not found

This has failed 7/7 times across:

2× deploymentRedeploy

3× serviceInstanceDeploy (fresh deploy)

1× purgeServiceCache(scope: ALL) followed by serviceInstanceDeploy

2× different commits (removed apps/copilot/.dockerignore in one attempt, apps/copilot/.railwayignore in another, each reverted after — neither changed the outcome)

Deployment IDs (chronological): 42217655, 163271a5, 9960eb3d, 5973c768, 7f696d4f, 4f7575e2, 7788a5da, [+1 more after railwayignore revert]

Key evidence this is NOT a source/content issue:

apps/copilot/prisma is a normal tracked git directory (verified via git ls-tree) — not a submodule, not a symlink, not excluded by any .dockerignore/.gitignore/.railwayignore.

The SAME commit (307bcdb / equivalent c7bf657) builds successfully on our dev environment (959b05d9), same project, same builder machine (builder-fmoiwh), same Railpack version (0.38.0) and image (mise-2026.8.13).

Across two DIFFERENT commits in this environment (one with apps/copilot/.dockerignore removed, one with apps/copilot/.railwayignore removed instead), the cache-key ref suffix in the error was IDENTICAL: k7wj9be0tbuc41h0mtq6wg52k::vv66jq5s4pzfhrymdx63s1g30. If this ref were content-addressed from the git tree it should have differed between two different commits — it didn't, which suggests a stuck/corrupted reference tied to (service, environment, path) rather than to commit content.

dev's successful build log shows an INCREMENTAL snapshot fetch (fetched snapshot ... modified file: apps/site/scripts/seed-pages.ts), while every prod attempt shows a FULL uploading snapshot — suggesting prod's service has no usable warm snapshot/cache state under the current Railpack version, and the fresh-context path is what's hitting the bug.

purgeServiceCache(scope: ALL) did not change the outcome or the ref hash, suggesting whatever is corrupted lives in a cache layer that purge doesn't reach.

Requested action: please reset/clear whatever internal build-cache or snapshot state is tied to this specific service in this environment (or reschedule it onto a different builder), since our own available levers (redeploy, fresh deploy, cache purge) haven't cleared it after 7 attempts.

Solved

0 Replies

Status changed to Awaiting Railway Response Railway • about 1 month ago


Status changed to Solved itrexru • about 1 month ago


Welcome!

Sign in to your Railway account to join the conversation.

Loading...