LCORE-1566: Update llama stack to 0.6.0#1396
LCORE-1566: Update llama stack to 0.6.0#1396jrobertboos wants to merge 1 commit intolightspeed-core:mainfrom
Conversation
WalkthroughDependencies are bumped to Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
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. Comment |
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
jrobertboos
force-pushed
the
lcore-1566
branch
2 times, most recently
from
897b83c to
360c5c2
Compare
fix missing dep potential fix konflux
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pyproject.toml`:
- Line 76: Add a brief justification for introducing "pypdf>=6.9.2" to the repo
by updating the PR description and the project metadata (e.g., README or
CHANGELOG) to state why pypdf is required; mention the exact dependency string
"pypdf>=6.9.2" and whether it is a direct runtime requirement, a transitive
dependency pinned to avoid breaking changes, or included for a specific feature;
if it was added mistakenly, remove "pypdf>=6.9.2" from pyproject.toml and
document that removal in the PR so the dependency list matches actual
requirements.
In `@requirements.hashes.source.txt`:
- Around line 877-885: The requirements.lock contains duplicate pypdf==6.9.2
entries (the two identical blocks listing sha256:662c... and sha256:7f85...) —
remove the redundant block so only a single pypdf==6.9.2 entry with its two
hashes remains; search for the duplicate pypdf==6.9.2 blocks and delete one,
then run any lockfile validation or dependency tooling you use to ensure no
other duplicates remain.
In `@src/app/endpoints/conversations_v1.py`:
- Line 6: The import for the ConversationNotFoundError is pointing at the wrong
module; update the import to reference the correct module path where the
exception is defined by replacing the current root-package import of
ConversationNotFoundError with an import from llama_stack_api.common.errors so
code that catches or raises ConversationNotFoundError (e.g., in conversations_v1
handlers) uses the actual exception class.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7a6991d5-a6ba-4d57-8077-41e4cedc565d
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (10)
pyproject.tomlrequirements-build.txtrequirements.hashes.source.txtrequirements.hashes.wheel.txtsrc/app/endpoints/conversations_v1.pysrc/app/endpoints/query.pysrc/app/endpoints/responses.pysrc/app/endpoints/streaming_query.pysrc/constants.pytests/e2e/features/info.feature
💤 Files with no reviewable changes (1)
- requirements.hashes.wheel.txt
📜 Review details
⏰ 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). (1)
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
🧰 Additional context used
📓 Path-based instructions (3)
tests/e2e/features/**/*.feature
📄 CodeRabbit inference engine (AGENTS.md)
Use behave (BDD) framework with Gherkin feature files for end-to-end tests
Files:
tests/e2e/features/info.feature
src/**/*.py
📄 CodeRabbit inference engine (AGENTS.md)
src/**/*.py: Use absolute imports for internal modules (e.g.,from authentication import get_auth_dependency)
Usefrom llama_stack_client import AsyncLlamaStackClientfor Llama Stack imports
Checkconstants.pyfor shared constants before defining new ones
All modules start with descriptive docstrings explaining purpose
Uselogger = get_logger(__name__)fromlog.pyfor module logging
Type aliases defined at module level for clarity
All functions require docstrings with brief descriptions
Use complete type annotations for function parameters and return types
Use union types with modern syntax:str | intinstead ofUnion[str, int]
UseOptional[Type]for optional types in type annotations
Use snake_case with descriptive, action-oriented names for functions (get_, validate_, check_)
Avoid in-place parameter modification anti-patterns: return new data structures instead of modifying parameters
Useasync deffor I/O operations and external API calls
HandleAPIConnectionErrorfrom Llama Stack in error handling
Uselogger.debug()for detailed diagnostic information
Uselogger.info()for general information about program execution
Uselogger.warning()for unexpected events or potential problems
Uselogger.error()for serious problems that prevented function execution
All classes require descriptive docstrings explaining purpose
Use PascalCase for class names with descriptive names and standard suffixes:Configuration,Error/Exception,Resolver,Interface
Use complete type annotations for all class attributes; avoid usingAny
Follow Google Python docstring conventions for all modules, classes, and functions
IncludeParameters:,Returns:,Raises:sections in function docstrings as needed
Files:
src/constants.pysrc/app/endpoints/query.pysrc/app/endpoints/conversations_v1.pysrc/app/endpoints/streaming_query.pysrc/app/endpoints/responses.py
src/app/**/*.py
📄 CodeRabbit inference engine (AGENTS.md)
src/app/**/*.py: Usefrom fastapi import APIRouter, HTTPException, Request, status, Dependsfor FastAPI dependencies
Use FastAPIHTTPExceptionwith appropriate status codes for API endpoint error handling
Files:
src/app/endpoints/query.pysrc/app/endpoints/conversations_v1.pysrc/app/endpoints/streaming_query.pysrc/app/endpoints/responses.py
🧠 Learnings (6)
📓 Common learnings
Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-05T12:19:36.009Z
Learning: Applies to src/**/*.py : Handle `APIConnectionError` from Llama Stack in error handling
📚 Learning: 2026-01-14T09:37:51.612Z
Learnt from: asimurka
Repo: lightspeed-core/lightspeed-stack PR: 988
File: src/app/endpoints/query.py:319-339
Timestamp: 2026-01-14T09:37:51.612Z
Learning: In the lightspeed-stack repository, when provider_id == "azure", the Azure provider with provider_type "remote::azure" is guaranteed to be present in the providers list. Therefore, avoid defensive StopIteration handling for next() when locating the Azure provider in providers within src/app/endpoints/query.py. This change applies specifically to this file (or nearby provider lookup code) and relies on the invariant that the Azure provider exists; if the invariant could be violated, keep the existing StopIteration handling.
Applied to files:
src/app/endpoints/query.py
📚 Learning: 2026-04-05T12:19:36.009Z
Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-05T12:19:36.009Z
Learning: Applies to src/**/*.py : Use `from llama_stack_client import AsyncLlamaStackClient` for Llama Stack imports
Applied to files:
pyproject.tomlrequirements.hashes.source.txt
📚 Learning: 2026-04-05T12:19:36.009Z
Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-05T12:19:36.009Z
Learning: Applies to src/**/*.py : Handle `APIConnectionError` from Llama Stack in error handling
Applied to files:
src/app/endpoints/conversations_v1.py
📚 Learning: 2026-04-05T12:19:36.009Z
Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-05T12:19:36.009Z
Learning: Applies to src/app/**/*.py : Use `from fastapi import APIRouter, HTTPException, Request, status, Depends` for FastAPI dependencies
Applied to files:
src/app/endpoints/conversations_v1.py
📚 Learning: 2026-04-05T12:19:36.009Z
Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-05T12:19:36.009Z
Learning: Applies to src/app/**/*.py : Use FastAPI `HTTPException` with appropriate status codes for API endpoint error handling
Applied to files:
src/app/endpoints/responses.py
🔇 Additional comments (16)
tests/e2e/features/info.feature (1)
19-19: LGTM!The expected llama-stack version is correctly updated to
0.6.0, consistent with the dependency bump inpyproject.tomland theMAXIMAL_SUPPORTED_LLAMA_STACK_VERSIONconstant insrc/constants.py.src/constants.py (1)
4-5: LGTM!The maximum supported version is correctly bumped to
0.6.0, matching the dependency version inpyproject.toml. The supported version range[0.2.17, 0.6.0]is consistent with the upgrade.pyproject.toml (1)
31-33: LGTM!The llama-stack ecosystem packages are correctly pinned to exact version
0.6.0, ensuring consistent builds across all three packages.src/app/endpoints/query.py (1)
305-310: LGTM!The error handling correctly normalizes the message once and checks for both
"context_length"and"context length"patterns, maintaining consistency with the same handling instreaming_query.py,responses.py, andrlsapi_v1.py. This accommodates potential variations in llama-stack error message formatting.requirements-build.txt (2)
67-68: LGTM!The
maturinversion bump from 1.10.2 to 1.12.6 is a build dependency update that aligns with the overall dependency refresh.
19-19: Transitive dependency addition noted.The
pypdfentry underflit-corereflects the newpypdf>=6.9.2runtime dependency added inpyproject.toml.src/app/endpoints/responses.py (2)
337-342: LGTM!The streaming response handler correctly normalizes the error message once and checks for both prompt-too-long patterns, consistent with other endpoints.
699-704: LGTM!The non-streaming response handler mirrors the same dual-check pattern, maintaining consistency with the streaming handler and other query endpoints.
src/app/endpoints/streaming_query.py (3)
356-361: LGTM!The
retrieve_response_generatorcorrectly handles prompt-too-longRuntimeErrorwith the dual-check pattern, consistent with other endpoints.
591-597: LGTM!The
generate_responseerror handling correctly normalizes once and checks both patterns in the conditional, producing eitherPromptTooLongResponseor a generic internal server error.
838-844: LGTM!The
response_generatorhandlesresponse.incompleteandresponse.failedevents by checking both context length patterns in the error message, consistent with the prompt-too-long detection elsewhere.src/app/endpoints/conversations_v1.py (3)
279-285: LGTM!The GET handler correctly catches both
APIStatusError(remote mode) andConversationNotFoundError(library mode), ensuring consistent 404 responses. The inline comment clearly explains the library-mode exception behavior.
387-392: LGTM!The DELETE handler appropriately treats both exception types as "already deleted" scenarios, with clear logging. This is the correct behavior for idempotent delete operations.
525-531: LGTM!The UPDATE handler consistently maps both exception types to a 404 response, maintaining parity with the GET handler behavior.
requirements.hashes.source.txt (2)
512-520: Version/hash bump blocks look consistent.The updated pinned versions and hash pairs for
llama-stack*,python-multipart, anduvicornare structurally correct for a hash-locked requirements file.Also applies to: 889-891, 1048-1050
512-520:⚠️ Potential issue | 🟠 MajorRemove duplicate
pypdf==6.9.2entry and add hashes forpillow==12.1.1to both lock files.The hash lock file is missing entries for
pillow==12.1.1, which is declared inrequirements.overrides.txt. Without these hashes, reproducible installs will fail. Additionally,pypdf==6.9.2appears twice in this file with identical hashes—remove the duplicate to clean up the lock manifest.⛔ Skipped due to learnings
Learnt from: CR Repo: lightspeed-core/lightspeed-stack PR: 0 File: AGENTS.md:0-0 Timestamp: 2026-04-05T12:19:36.009Z Learning: Applies to src/**/*.py : Use `from llama_stack_client import AsyncLlamaStackClient` for Llama Stack imports
| # To be able to fix multiple CVEs, also LCORE-1117 | ||
| "requests>=2.33.0", | ||
| "datasets>=4.7.0", | ||
| "pypdf>=6.9.2", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify pypdf package version exists and check llama-stack dependencies
# Check PyPI for pypdf versions
echo "=== Checking pypdf on PyPI ==="
curl -s https://pypi.org/pypi/pypdf/json | jq '.info.version, .releases | keys | last'
# Check if llama-stack 0.6.0 lists pypdf as a dependency
echo "=== Checking llama-stack 0.6.0 dependencies ==="
curl -s https://pypi.org/pypi/llama-stack/0.6.0/json | jq '.info.requires_dist | map(select(startswith("pypdf")))'Repository: lightspeed-core/lightspeed-stack
Length of output: 229
Clarify why pypdf>=6.9.2 was added as a dependency.
Verification confirms pypdf 6.9.2+ exists on PyPI, but it is NOT listed as a dependency of llama-stack 0.6.0. This dependency appears to be unrelated to llama-stack's actual requirements. Explain the reason for adding it to this project.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@pyproject.toml` at line 76, Add a brief justification for introducing
"pypdf>=6.9.2" to the repo by updating the PR description and the project
metadata (e.g., README or CHANGELOG) to state why pypdf is required; mention the
exact dependency string "pypdf>=6.9.2" and whether it is a direct runtime
requirement, a transitive dependency pinned to avoid breaking changes, or
included for a specific feature; if it was added mistakenly, remove
"pypdf>=6.9.2" from pyproject.toml and document that removal in the PR so the
dependency list matches actual requirements.
There was a problem hiding this comment.
interesting question from bot ^^^ :)
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
echo "=== Searching for pypdf imports or usage in Python files ==="
rg -n "pypdf" --type py -C2
echo ""
echo "=== Searching for pypdf in all files ==="
rg -n "pypdf" -C2
echo ""
echo "=== Check what llama-stack 0.6.0 depends on that might pull in pypdf ==="
curl -s https://pypi.org/pypi/llama-stack/0.6.0/json | jq '.info.requires_dist[]' | grep -i "pdf" || echo "No pdf-related deps found in llama-stack 0.6.0"
echo ""
echo "=== Check llama-stack-client 0.6.0 dependencies ==="
curl -s https://pypi.org/pypi/llama-stack-client/0.6.0/json | jq '.info.requires_dist[]' | grep -i "pdf" || echo "No pdf-related deps found in llama-stack-client 0.6.0"
Length of output: 3928
@tisnik — Mystery solved! 🔍 The answer is in docs/providers.md:
rag-runtime | inline | chardet, pypdf, tqdm, numpy, ...✅
pypdf is a direct runtime dependency required for the inline rag-runtime provider (used to parse PDF documents in RAG pipelines). It's not pulled in transitively by llama-stack itself — it's an explicit requirement of the RAG feature that this project supports.
So the addition is valid and intentional. It might just be worth adding a comment next to it in pyproject.toml for clarity, similar to other entries:
# Used for PDF document parsing by rag-runtime provider
"pypdf>=6.9.2",🧠 Learnings used
Learnt from: CR
Repo: lightspeed-core/lightspeed-stack PR: 0
File: AGENTS.md:0-0
Timestamp: 2026-04-05T12:19:36.009Z
Learning: Always check `pyproject.toml` for existing dependencies before adding new ones
| pypdf==6.9.2 \ | ||
| --hash=sha256:662cf29bcb419a36a1365232449624ab40b7c2d0cfc28e54f42eeecd1fd7e844 \ | ||
| --hash=sha256:7f850faf2b0d4ab936582c05da32c52214c2b089d61a316627b5bfb5b0dab46c | ||
| pythainlp==5.3.4 \ | ||
| --hash=sha256:76744e51e27c895630bafd74f53a1f0aa8782cef2f7f02eebd6427fe8ce8d84d \ | ||
| --hash=sha256:e66fd76fb5931834fd4e32ed54337ec62350d7654f187850e4dd4f915e9f624f | ||
| pypdf==6.9.2 \ | ||
| --hash=sha256:662cf29bcb419a36a1365232449624ab40b7c2d0cfc28e54f42eeecd1fd7e844 \ | ||
| --hash=sha256:7f850faf2b0d4ab936582c05da32c52214c2b089d61a316627b5bfb5b0dab46c |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== duplicate package blocks in requirements.hashes.source.txt =="
rg -n '^[a-zA-Z0-9_.-]+==[^\s]+' requirements.hashes.source.txt \
| awk -F'[:=]' '{print $3}' \
| sort | uniq -cd | sort -nr
echo
echo "== pypdf occurrences =="
rg -n '^pypdf==6\.9\.2' requirements.hashes.source.txt -nRepository: lightspeed-core/lightspeed-stack
Length of output: 212
Remove duplicate pypdf==6.9.2 lock entry.
Lines 877–879 and 883–885 contain identical pypdf==6.9.2 blocks with the same hashes. Keep only one entry.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@requirements.hashes.source.txt` around lines 877 - 885, The requirements.lock
contains duplicate pypdf==6.9.2 entries (the two identical blocks listing
sha256:662c... and sha256:7f85...) — remove the redundant block so only a single
pypdf==6.9.2 entry with its two hashes remains; search for the duplicate
pypdf==6.9.2 blocks and delete one, then run any lockfile validation or
dependency tooling you use to ensure no other duplicates remain.
| from typing import Any | ||
|
|
||
| from fastapi import APIRouter, Depends, HTTPException, Request | ||
| from llama_stack_api import ConversationNotFoundError |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Verify ConversationNotFoundError exists in llama-stack-api
# Search for ConversationNotFoundError in llama-stack-api package documentation or source
echo "=== Checking llama-stack-api for ConversationNotFoundError ==="
pip index versions llama-stack-api 2>/dev/null || echo "pip index not available"
# Try to find the exception in installed package (if available in test env)
python -c "from llama_stack_api import ConversationNotFoundError; print('ConversationNotFoundError found:', ConversationNotFoundError)" 2>&1 || echo "Package not installed or exception not found"Repository: lightspeed-core/lightspeed-stack
Length of output: 336
🏁 Script executed:
# Find dependency files that specify llama-stack-api version
find . -type f \( -name "requirements*.txt" -o -name "pyproject.toml" -o -name "setup.py" -o -name "setup.cfg" \) | head -20Repository: lightspeed-core/lightspeed-stack
Length of output: 239
🏁 Script executed:
# Examine the actual file to understand context
cat -n src/app/endpoints/conversations_v1.py | head -50Repository: lightspeed-core/lightspeed-stack
Length of output: 1886
🏁 Script executed:
# Check if there are any other files that import ConversationNotFoundError
rg "ConversationNotFoundError" --type pyRepository: lightspeed-core/lightspeed-stack
Length of output: 840
🏁 Script executed:
# Check pyproject.toml for llama-stack-api version
cat pyproject.toml | grep -A 20 -B 2 "llama"Repository: lightspeed-core/lightspeed-stack
Length of output: 1589
🌐 Web query:
llama-stack-api 0.6.0 ConversationNotFoundError exception documentation
💡 Result:
In llama-stack-api==0.6.0, ConversationNotFoundError is defined in llama_stack_api.common.errors as a subclass of ResourceNotFoundError (which maps to HTTP 404 Not Found). It’s used when Llama Stack can’t find the referenced conversation ID. [1][2]
Definition / import path
from llama_stack_api.common.errors import ConversationNotFoundErrorIt’s implemented as:
class ConversationNotFoundError(ResourceNotFoundError): ...__init__(self, conversation_id: str)→super().__init__(conversation_id, resource_type="Conversation")[1]
Version note: llama-stack-api 0.6.0 was released Mar 11, 2026. [3]
Sources
[1] https://github.com/llamastack/llama-stack/blob/v0.6.0/src/llama_stack_api/common/errors.py
[2] https://github.com/llamastack/llama-stack/blob/v0.6.0/src/llama_stack_api/common/errors.py (ResourceNotFoundError docs / HTTP 404 mapping)
[3] https://pypi.org/project/llama-stack-api/
Fix incorrect import path for ConversationNotFoundError.
The exception ConversationNotFoundError exists in llama-stack-api==0.6.0, but the import statement uses the wrong module path. Change line 6 from:
from llama_stack_api import ConversationNotFoundErrorto:
from llama_stack_api.common.errors import ConversationNotFoundErrorThe exception is defined in llama_stack_api.common.errors, not directly exported from the llama_stack_api package root.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@src/app/endpoints/conversations_v1.py` at line 6, The import for the
ConversationNotFoundError is pointing at the wrong module; update the import to
reference the correct module path where the exception is defined by replacing
the current root-package import of ConversationNotFoundError with an import from
llama_stack_api.common.errors so code that catches or raises
ConversationNotFoundError (e.g., in conversations_v1 handlers) uses the actual
exception class.
|
Very exciting! 🚀 |
| pyopenssl==26.0.0 \ | ||
| --hash=sha256:df94d28498848b98cc1c0ffb8ef1e71e40210d3b0a8064c9d29571ed2904bf81 \ | ||
| --hash=sha256:f293934e52936f2e3413b89c6ce36df66a0b34ae1ea3a053b8c5020ff2f513fc | ||
| pypdf==6.9.2 \ |
There was a problem hiding this comment.
it's there two times, why?
| error_response = ( | ||
| PromptTooLongResponse(model=responses_params.model) | ||
| if "context_length" in str(e).lower() | ||
| if "context_length" in error_msg or "context length" in error_msg |
There was a problem hiding this comment.
repeated twice -> better to refactor into small utility function
| # To be able to fix multiple CVEs, also LCORE-1117 | ||
| "requests>=2.33.0", | ||
| "datasets>=4.7.0", | ||
| "pypdf>=6.9.2", |
There was a problem hiding this comment.
interesting question from bot ^^^ :)
3 participants
Description
Type of change
Tools used to create PR
Identify any AI code assistants used in this PR (for transparency and review context)
Related Tickets & Documents
Checklist before requesting a review
Testing
Summary by CodeRabbit
Release Notes
Updates
Bug Fixes