fix(deps): pin graphrag-sdk to <0.9.0 and build image from uv.lock - #723
fix(deps): pin graphrag-sdk to <0.9.0 and build image from uv.lock#723galshubeli merged 3 commits into
Conversation
Sorry, something went wrong.
graphrag-sdk 1.x is a full rewrite that removed `graphrag_sdk.models` and the `Ontology`/`KnowledgeGraph`/`KnowledgeGraphModelConfig` public API that `api/llm.py` depends on. #673 widened the constraint to `<1.2.0`, so a fresh resolve picks 1.1.1 and the app crashes on import: File "/app/api/llm.py", line 7, in <module> from graphrag_sdk.models.litellm import LiteModel ModuleNotFoundError: No module named 'graphrag_sdk.models' CI stayed green because `uv sync` honours uv.lock (still 0.8.2), while the Docker image ran `pip install .` straight from pyproject.toml and resolved the newest allowed version. Restore the `<0.9.0` upper bound and install the image's dependencies under constraints exported from uv.lock so the container can no longer drift from the lockfile. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: db9fd55d-2b45-4600-8606-e6261bf46cc5 📥 CommitsReviewing files that changed from the base of the PR and between 0f7f63c and 8aa9ec5. 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 2 included reviews per hour; 0 remain after this review. 📝 Walkthrough WalkthroughThe project restricts graphrag-sdk to versions below 0.9.0. The Docker image pins uv to version 0.12.5, exports frozen production constraints, removes uv, and installs the application with those constraints. ChangesDependency and container installation
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to 8aa9e The change pins the compatible SDK version and makes the image install from the lockfile, preventing dependency drift that caused startup failures; no actionable merge-blocking risk remains after normal checks and review. 🚥 Pre-merge checks | ✅ 5 ✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. ❤️ ShareComment @coderabbitai help to get the list of available commands. |
Sorry, something went wrong.
There was a problem hiding this comment.
Pull request overview
This PR fixes a production-only dependency mismatch that caused Railway deployments to crash-loop by (1) re-pinning graphrag-sdk to the pre-1.0 API surface expected by api/llm.py, and (2) ensuring Docker image builds install Python dependencies in a way that cannot drift from uv.lock (matching CI resolution behavior).
Changes:
- Restores the graphrag-sdk upper bound to <0.9.0 to avoid the incompatible 1.x rewrite.
- Updates uv.lock metadata to reflect the narrowed graphrag-sdk specifier (while keeping the resolved version at 0.8.2).
- Updates the Dockerfile to export pinned constraints from uv.lock (uv export --frozen) and install under pip -c, preventing re-resolution drift during image builds.
Reviewed changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| uv.lock | Narrows the recorded graphrag-sdk specifier to <0.9.0 to match the intended compatibility range. |
| pyproject.toml | Pins graphrag-sdk to <0.9.0 so graphrag_sdk.models.* imports remain valid. |
| Dockerfile | Installs Python deps using constraints exported from uv.lock to keep container deps aligned with CI/lockfile. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
| RUN pip install --no-cache-dir --break-system-packages uv \ | ||
| && uv export --frozen --no-dev --no-emit-project --no-hashes -o /tmp/constraints.txt \ | ||
| && pip install --no-cache-dir --break-system-packages -c /tmp/constraints.txt . \ |
There was a problem hiding this comment.
Good catch — and a fair point given this PR is precisely about unpinned dependency drift. Leaving uv unpinned reintroduced the same failure mode one layer up: uv export --frozen produces the constraints file, so an upstream uv release changing CLI flags or export semantics could break image builds with no change on our side.
Fixed in 0f7f63c:
ARG UV_VERSION=0.12.5
COPY pyproject.toml uv.lock ./
RUN pip install --no-cache-dir --break-system-packages "uv==${UV_VERSION}" \\
&& uv export --frozen --no-dev --no-emit-project --no-hashes -o /tmp/constraints.txt \\
...Used an ARG so the version stays overridable at build time (--build-arg UV_VERSION=...) without editing the Dockerfile.
Verified with a real image build: uv 0.12.5 installs, reads the revision = 2 lockfile under --frozen, resolves graphrag-sdk 0.8.2, and from graphrag_sdk.models.litellm import LiteModel succeeds inside the container.
Sorry, something went wrong.
`uv export --frozen` is on the critical path for producing the constraints file, so installing uv unpinned reintroduces exactly the drift this branch removes: an upstream release could change CLI flags or export semantics and break image builds without any change here. Pin via an `ARG UV_VERSION` so the version is overridable at build time without editing the Dockerfile. Addresses review feedback on #723. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| RUN pip install --no-cache-dir --break-system-packages "uv==${UV_VERSION}" \ | ||
| && uv export --frozen --no-dev --no-emit-project --no-hashes -o /tmp/constraints.txt \ | ||
| && pip install --no-cache-dir --break-system-packages -c /tmp/constraints.txt . \ | ||
| && rm /tmp/constraints.txt |
There was a problem hiding this comment.
Agreed — uv was dead weight in the runtime. Fixed in 8aa9ec5 by uninstalling it in the same RUN layer, so it never lands in the shipped layer at all (uninstalling in a later layer would leave the bytes in the earlier one):
RUN pip install --no-cache-dir --break-system-packages "uv==${UV_VERSION}" \\
&& uv export --frozen --no-dev --no-emit-project --no-hashes -o /tmp/constraints.txt \\
&& pip uninstall -y --break-system-packages uv \\
&& pip install --no-cache-dir --break-system-packages -c /tmp/constraints.txt . \\
&& rm /tmp/constraints.txtSaves ~23MB (the uv manylinux wheel is 22.6MB compressed) plus the associated dependency/CVE surface.
Verified in a real image build:
OK: uv binary gone OK: uv package gone OK: imports work Name: graphrag-sdk Version: 0.8.2
Sorry, something went wrong.
uv is only needed to generate the constraints file; nothing later in the Dockerfile or start.sh uses it. Uninstall it in the same RUN layer so it never persists into the shipped image, avoiding ~23MB of dead weight and the extra dependency/CVE surface in the runtime. Addresses review feedback on #723. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
| # upgrade could change `uv export` semantics and break reproducibility. | ||
| # It is removed in the same layer, since only the export step needs it. | ||
| ARG UV_VERSION=0.12.5 | ||
| COPY pyproject.toml uv.lock ./ |
There was a problem hiding this comment.
Investigated this one and it turned out to be more than a metadata nit — thanks for pushing on it.
On the README specifically: I tested it, and current setuptools tolerates the missing file (it warns rather than fails), so metadata generation was not actually breaking:
README.md present: False METADATA OK: falkordb_code_graph-0.4.2.dist-info
But the underlying concern was real, and worse than fragile metadata. Because pip install . ran with no sources present, [tool.setuptools.packages.find] matched nothing — so the api package, the api.mcp templates package-data, and the console scripts never reached site-packages. A console script resolves imports from its own bin directory rather than the working directory, so both entry points were dead in the image:
api installed: False cgraph BROKEN cgraph-mcp BROKEN
That means the documented CGRAPH_MODE=mcp path in start.sh (exec cgraph-mcp) could never have started. Web mode only worked by accident, because uvicorn adds the working directory to the import path.
Fix (bbd4118) — took your second suggestion, splitting the install so the dependency layer stays cache-friendly:
# deps only, pinned from uv.lock
RUN ... uv export --frozen ... -o /tmp/requirements.txt \
&& pip uninstall -y --break-system-packages uv \
&& pip install --no-cache-dir --break-system-packages -r /tmp/requirements.txt
...
COPY ./api ./api
COPY README.md ./
RUN pip install --no-cache-dir --break-system-packages --no-deps .Verified on a full build of the real Dockerfile:
OK: uv gone
graphrag-sdk Version: 0.8.2
api installed: True
cgraph OK <- run from / , not /app
cgraph-mcp OK <- run from / , not /app
templates dir: .../site-packages/api/mcp/templates exists: True
['claude_mcp_section.md', 'cursorrules.template']
STATIC_DIR: /app/app/dist exists: True
Plus runtime smoke tests of both modes:
- web — container boots to Application startup complete, GET /api/list_repos returns 200 {"status":"success","repositories":[]}, and GET / serves the SPA with 200
- mcp — CGRAPH_MODE=mcp now answers a JSON-RPC initialize, returning serverInfo.name = "code-graph"
No regression to web mode: STATIC_DIR still resolves against /app/api, because the working directory takes precedence over site-packages on the import path.
Sorry, something went wrong.
Summary
Railway deployments of staging crash-loop on startup with:
File "/app/api/llm.py", line 7, in <module> from graphrag_sdk.models.litellm import LiteModel ModuleNotFoundError: No module named 'graphrag_sdk.models'Two independent problems combined to cause this:
The version constraint was too wide. chore(deps): Update graphrag-sdk requirement from <0.9.0,>=0.8.1 to >=0.8.1,<1.2.0 #673 widened graphrag-sdk from <0.9.0 to <1.2.0. graphrag-sdk 1.x is a complete rewrite — it dropped the graphrag_sdk.models subpackage and the entire Ontology / Entity / Relation / KnowledgeGraph / KnowledgeGraphModelConfig surface that api/llm.py imports. Verified against the published wheels:
A clean pip install "graphrag-sdk>=0.8.1,<1.2.0" resolves to 1.1.1, so import api fails before uvicorn can start.
The image ignored the lockfile. uv.lock still pinned 0.8.2, so uv sync in CI kept working and every workflow stayed green. The Dockerfile, however, ran pip install . directly against pyproject.toml, which re-resolved to the newest allowed version. That is why this only ever reproduced in the deployed container and never in CI.
Changes
Testing
Memory / Performance Impact
N/A — dependency pinning and build configuration only. No runtime code changed.
Related Issues
Regression introduced by #673.
Summary by CodeRabbit
Chores
Bug Fixes