[Fix] Docker: restore pre-uv Prisma cache path

[yuneng-berri]

Relevant issues

Summary

Failure Path (Before Fix)

When a deployment mounts a volume at /app/.cache (common with securityContext.readOnlyRootFilesystem: true plus an emptyDir for a writable cache), the proxy fails at startup:

prisma.engine.errors.BinaryNotFoundError: Expected /app/prisma-query-engine-debian-openssl-3.6.x
or /app/.cache/prisma-python/binaries/prisma-query-engine-debian-openssl-3.6.x to exist but
neither were found or could not be executed.

The uv migration (#25007) added PRISMA_BINARY_CACHE_DIR=/app/.cache/... and XDG_CACHE_HOME=/app/.cache to the runtime stages of Dockerfile and Dockerfile.database. The generated prisma client's BINARY_PATHS was baked to point into /app/.cache. Any volume mount shadowing that directory removes the pre-downloaded query engine at pod startup.

Before the uv migration the binaries lived in /root/.cache (prisma-python's default under HOME=/root) and were unaffected by /app/* mounts.

Fix

Drop the two env vars from the runtime stage, then re-run prisma generate there. With no override, prisma-python defaults to $HOME/.cache = /root/.cache, so both the downloaded query engine and the baked BINARY_PATHS land outside /app. Remove the stale builder-stage /app/.cache afterwards (~800 MB it would otherwise carry unused).

Dockerfile.non_root is intentionally unchanged — its /app/.cache location is by design for the hardened offline-install flow.

Testing

Built both fixed images and ran a three-scenario matrix against a local Postgres:

Scenario	Result
No volume mount	CONNECTED
docker run --tmpfs /app/.cache (reproduces pre-fix failure exactly)	CONNECTED
docker run --read-only --tmpfs /tmp --tmpfs /app/.cache --tmpfs /app/.npm	CONNECTED

Verified BINARY_PATHS in the generated client resolves to /root/.cache/prisma-python/binaries/5.4.2/<engine-hash>/node_modules/prisma/query-engine-* on both Dockerfile and Dockerfile.database outputs.

Type

🐛 Bug Fix
🚄 Infrastructure

[greptile-apps]

Greptile Summary

This PR fixes a startup failure (BinaryNotFoundError) that occurred when /app/.cache was shadowed by a volume mount (e.g. readOnlyRootFilesystem + emptyDir) by moving Prisma's binary cache out of /app and into /root/.cache, which is the prisma-python default when PRISMA_BINARY_CACHE_DIR and XDG_CACHE_HOME are unset. The implementation — removing the two env vars from both stages and copying /root/.cache from the builder — is sound and avoids a redundant network download, directly addressing the concern raised in a prior review thread.

Confidence Score: 5/5

Safe to merge — the core fix is correct and the only remaining finding is a P2 image-size suggestion.

All findings are P2 style/cleanup suggestions. The fix correctly roots out the bug, the binary path baked into the generated client now matches where the binary lands at runtime, and the COPY-from-builder approach avoids any network dependency in the runtime layer build.

Dockerfile and docker/Dockerfile.database — both have the same broad /root/.cache copy that could be narrowed to /root/.cache/prisma-python.

Important Files Changed

Filename	Overview
Dockerfile	Removes PRISMA_BINARY_CACHE_DIR and XDG_CACHE_HOME from both builder and runtime stages; adds COPY --from=builder /root/.cache /root/.cache — correct fix but copies the full root cache tree (including uv cache) rather than just the prisma-python subtree.
docker/Dockerfile.database	Identical changes to Dockerfile — correct fix, same overly broad /root/.cache copy concern applies.

Sequence Diagram

sequenceDiagram
    participant B as builder stage
    participant R as runtime stage
    participant D as Deployment (pod)

    Note over B: prisma generate (no PRISMA_BINARY_CACHE_DIR)<br/>defaults to $HOME/.cache = /root/.cache
    B->>B: write binary → /root/.cache/prisma-python/binaries/…
    B->>B: write client BINARY_PATHS → /root/.cache/…

    B->>R: COPY /app → /app (includes generated client)
    B->>R: COPY /root/.cache → /root/.cache (includes query engine binary)

    Note over D: volume mount on /app/.cache has no effect
    D->>R: container start
    R->>R: prisma client resolves BINARY_PATHS → /root/.cache/… ✓

Loading

_{Reviews (3): Last reviewed commit: "Merge remote-tracking branch 'origin/lit..." | Re-trigger Greptile}

[greptile-apps]

Binary re-download adds unnecessary network dependency

The rm -rf /app/.cache discards the query engine binary already downloaded by the builder, and prisma generate then fetches it again from the internet into /root/.cache. This doubles the download time and requires outbound internet access from the runtime layer — which may fail in air-gapped or --network=none build environments.

Consider copying the binary from the builder's /app/.cache into /root/.cache before running prisma generate, so the download only happens once.