LCORE-1062: Dependencies update

[tisnik]

Description

LCORE-1062: Dependencies update

Type of change

• Refactor
• New feature
• Bug fix
• CVE fix
• Optimization
• Documentation Update
• Configuration Update
• Bump-up service version
• Bump-up dependent library
• Bump-up library or tool used for development (does not change the final image)
• CI configuration change
• Konflux configuration change
• Unit tests improvement
• Integration tests improvement
• End to end tests improvement

Tools used to create PR

Identify any AI code assistants used in this PR (for transparency and review context)

• Assisted-by: N/A
• Generated by: N/A

Related Tickets & Documents

• Related Issue #LCORE-1062

Summary by CodeRabbit

• Chores
  • Updated project dependencies to their latest versions across supported architectures.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Dependencies are updated across architecture-specific requirements files. fastapi bumped from 0.126.0 to 0.127.0, uvicorn from 0.38.0 to 0.40.0, and importlib-metadata from 8.7.0 to 8.7.1. Corresponding package hashes are updated to reflect new versions. No code changes or new APIs introduced.

Changes

Cohort / File(s)	Summary
Architecture-specific dependency updates requirements.aarch64.txt, requirements.x86_64.txt	Updated package versions: fastapi (0.126.0 → 0.127.0), uvicorn (0.38.0 → 0.40.0), importlib-metadata (8.7.0 → 8.7.1). Updated corresponding package hashes to align with new versions.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

• These are straightforward mechanical dependency version and hash updates with no functional code changes.

Possibly related PRs

• PR #871: Modifies the same architecture-specific requirements files with overlapping dependency bumps (fastapi).
• PR #862: Updates the same requirements files with overlapping package version/hash changes (fastapi, uvicorn, importlib-metadata).
• PR #911: Modifies autogenerated requirements files and bumps fastapi dependency and hashes in the same requirements.*.txt files.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'LCORE-1062: Dependencies update' clearly and accurately describes the main change—updating dependency versions in requirements files.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 51dfd24 and 8c82299.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• requirements.aarch64.txt
• requirements.x86_64.txt

🧰 Additional context used

🧠 Learnings (2)

📚 Learning: 2025-08-18T10:57:39.266Z

Learnt from: matysek
Repo: lightspeed-core/lightspeed-stack PR: 292
File: pyproject.toml:59-59
Timestamp: 2025-08-18T10:57:39.266Z
Learning: In the lightspeed-stack project, transitive dependencies like faiss-cpu are intentionally pinned as top-level dependencies to maintain better control over the dependency graph and avoid version conflicts when bundling ML/LLM tooling packages.

Applied to files:

• requirements.x86_64.txt
• requirements.aarch64.txt

📚 Learning: 2025-08-18T10:58:14.951Z

Learnt from: matysek
Repo: lightspeed-core/lightspeed-stack PR: 292
File: pyproject.toml:47-47
Timestamp: 2025-08-18T10:58:14.951Z
Learning: psycopg2-binary is required by some llama-stack providers in the lightspeed-stack project, so it cannot be replaced with psycopg v3 or moved to optional dependencies without breaking llama-stack functionality.

Applied to files:

• requirements.x86_64.txt
• requirements.aarch64.txt

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (8)

• GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
• GitHub Check: build-pr
• GitHub Check: E2E: library mode / ci
• GitHub Check: E2E: server mode / azure
• GitHub Check: E2E: server mode / vertexai
• GitHub Check: E2E: library mode / vertexai
• GitHub Check: E2E: server mode / ci
• GitHub Check: E2E: library mode / azure

🔇 Additional comments (6)

requirements.x86_64.txt (3)

659-661: FastAPI bump to 0.127.0 looks good; ensure no reliance on pydantic.v1 shims

The version and hashes look consistent with the upstream 0.127.0 release. This release mainly adds deprecation warnings around pydantic.v1 usage on top of 0.126.0, which had already dropped Pydantic v1 and required pydantic>=2.7.0. Your pinned pydantic==2.12.5 satisfies this, so no incompatibility is obvious; just confirm nothing in your stack still depends on pydantic.v1 behavior and that integration tests pass. (fastapi.tiangolo.com)

---

1141-1143: Minor importlib‑metadata micro‑bump; low risk but still worth running tests

Moving to importlib-metadata==8.7.1 is a small step over 8.7.x and should be low risk, especially on Python 3.12 where stdlib importlib.metadata already provides most functionality. I don’t see any red flags, but please run your usual test suite and any packaging/CLI sanity checks to confirm there are no subtle metadata lookup regressions. (pypi.org)

---

3585-3587: Uvicorn bump to 0.40.0 looks correct; validate FastAPI/Starlette stack at runtime

The uvicorn==0.40.0 pin and hashes align with the latest PyPI release. Given the closely‑coupled trio (FastAPI 0.127.0, Starlette 0.50.0, Uvicorn 0.40.0), this combination should be fine, but I recommend a quick smoke test of your ASGI stack (startup/shutdown hooks, websockets, SSE, and HTTP/2 if used) to ensure no behavioral changes slipped in. (fastapi.tiangolo.com)

requirements.aarch64.txt (3)

659-661: fastapi bump and hashes look correct; just ensure runtime tests cover this very fresh release

The pinned version (0.127.0) and both hashes match the current PyPI artifacts; no issues in the compiled entry itself. Given how new this release is, it’s worth running your FastAPI/Starlette integration tests and a quick smoke test of the HTTP stack (including docs and SSE) on both x86_64 and aarch64 to catch any regressions. (pypi.org)

---

1141-1143: importlib-metadata pin is consistent with PyPI; verify that all supported Python versions still behave as expected

Version 8.7.1 and its hashes match the latest PyPI release, so the entry itself is sound. Because this library can subtly affect plugin/entry‑point discovery, I recommend running your test suite on all CI Python versions (esp. 3.12 used in the compile command) to confirm no import/discovery regressions. (pypi.org)

---

3585-3587: uvicorn bump is correct and hashes match; please smoke‑test server startup and lifecycle

The 0.40.0 pin and hashes align with the latest uvicorn release on PyPI, so the requirements entry is correct. Given the jump from 0.38.x to 0.40.0 and its impact on ASGI serving, I’d suggest a brief manual smoke test (startup, shutdown, hot‑reload if used) to confirm everything still works with your FastAPI/Starlette stack. (pypi.org)

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}