Hi Railway team,

We are experiencing a Railway-specific build issue that is currently unexplained.

Project: pacific-alignment

Service: Educare

Environment: staging

GitHub repository:

aboalneel/Educare

Branch: staging

Root directory: apps/web

The last successful deployment was:

Commit: 5e4f314

Deployment: 000610f5

Status: SUCCESS

Immediately after that, the very next deployment failed:

Commit: 7eed3ff

Deployment: 79cb2bc5

Status: FAILED

The important detail is that the Git diff between these two commits contains ONLY:

apps/web/tests/virtual-school-acceptance.test.ts

864 lines added.

There were ZERO changes anywhere under apps/web/src/.

The successful build explicitly compiled these routes:

/admin/academic-years

/admin/admissions

The next build failed with:

./src/app/(dashboard)/admin/academic-years/page.tsx

Module not found: Can't resolve '@/lib/permissions'

Module not found: Can't resolve '@/lib/db'

Module not found: Can't resolve '@/components/admin/AcademicYearManager'

./src/app/(dashboard)/admin/admissions/page.tsx

Module not found: Can't resolve '@/lib/permissions'

Module not found: Can't resolve '@/lib/db'

The exact same failure signature has persisted through subsequent deployments:

fdf58cf

b0f624f

c96b5b3

080f4ba

caf1347

We have investigated the application side extensively:

• All affected files exist and are Git-tracked.

• Correct filename casing has been verified.

• No case-only duplicates exist.

• No .gitignore/.dockerignore rule excludes them.

• The deployed commit contains the expected files.

• tsconfig.json uses the standard alias:

  "baseUrl": "."

  "paths": { "@/": ["./src/"] }

• next.config.js has no custom webpack alias.

• The same @/lib/permissions and @/lib/db imports work in approximately 55 other files in the same application.

• Known-good pages use the same import pattern.

• Fresh local builds of the exact failing commits succeed.

• GitHub Actions CI builds the same commits successfully.

• Railway is now using Node 24 and npm ci succeeds.

• The Railway build reaches npm run build and fails inside next build.

• We successfully cleared the BuildKit cache mounts before deployment ea8e474b, but the exact same module-resolution failure remained.

• We also tested directory traversal/order dependence locally; both normal and altered ordering built successfully.

Railway build logs consistently show source snapshot behavior such as:

uploading snapshot

fetched snapshot sha256:...

fetching snapshot

modified file: ...

unpacking archive

This behavior also existed in the last successful build, so we are NOT assuming incremental snapshots are inherently the problem.

However, the unexplained point is that a commit whose relevant application source is byte-for-byte unchanged from a known-good deployment suddenly fails to resolve existing tracked modules on Railway, while the exact same source builds successfully locally and in GitHub Actions.

Could you please investigate this server-side?

Specifically:

1. Can you inspect the actual source snapshot/build context materialized for deployment 79cb2bc5 and compare it with 000610f5?

2. Can you confirm whether the following files were present in the failing build context with the expected paths and contents?

apps/web/src/app/(dashboard)/admin/academic-years/page.tsx

apps/web/src/app/(dashboard)/admin/admissions/page.tsx

apps/web/src/lib/permissions.ts

apps/web/src/lib/db.ts

apps/web/src/components/admin/AcademicYearManager.tsx

1. Can you confirm the source snapshot SHA and base snapshot used for deployment 79cb2bc5?

2. Could the incremental snapshot/delta mechanism have produced an incomplete or inconsistent source tree?

3. Is there an officially supported way to invalidate/rebuild the Railway-side source snapshot itself, distinct from Docker/Next.js build caches?

4. Does disconnecting/reconnecting the GitHub repository force a fresh source snapshot, or does it only reset the GitHub source/webhook connection?

5. Are there any known Railway/Railpack issues involving monorepos, rootDirectory builds, incremental snapshots, or Next.js/Webpack module resolution that could cause this exact behavior?

6. Can you inspect the internal build filesystem/context for one of the failing deployments and determine why Webpack reports these modules as unresolved?

We are not asserting that Railway is necessarily at fault. We would like to understand the actual server-side mechanism before making any undocumented or potentially disruptive changes to the source connection.

Deployment references:

Last successful:

000610f5

First failure:

79cb2bc5

Latest failed deployment:

ea8e474b

Project ID:

4b95192d-7b5e-4689-9cc2-2638206c3433

Service ID:

bc19dc78-e8dc-42e7-a41b-5498bd356116

Environment ID:

ce4b04cf-0c4f-47f6-abdc-3b2a385aba83

Thank you.