pre-import llm jobs module on worker starutp#715
Conversation
📝 WalkthroughWalkthroughThis PR updates Celery worker initialization and configuration. It adds a signal handler to preload LLM modules on worker startup and adjusts worker resource limits by increasing max tasks per child worker from 1 to 150 and max memory per child worker from 200000 to 300000. Changes
Possibly related PRs
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@backend/app/celery/celery_app.py`:
- Line 13: The function warm_llm_modules currently uses an untyped variadic
kwargs parameter (**_), which breaks the repository typing rule; update the
signature to use an explicit type hint for ignored signal kwargs (change **_ to
**_: Any) and ensure Any is imported from typing if not already present, keeping
the existing return annotation -> None and the function name warm_llm_modules to
locate the change.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 6eb5d39c-cf89-4966-8b96-54b404640cc9
📒 Files selected for processing (2)
backend/app/celery/celery_app.pybackend/app/core/config.py
|
|
||
|
|
||
| @worker_process_init.connect | ||
| def warm_llm_modules(**_) -> None: |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n backend/app/celery/celery_app.py | head -30Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 1110
🏁 Script executed:
rg "def.*\*\*" backend/app/celery/celery_app.py -A 2 -B 2Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 215
🏁 Script executed:
rg "def.*\*\*" --type py -A 1 | head -50Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 3467
🏁 Script executed:
head -20 backend/app/celery/celery_app.pyRepository: ProjectTech4DevAI/kaapi-backend
Length of output: 673
🏁 Script executed:
rg "from typing import|import typing" backend/app/celery/ --type pyRepository: ProjectTech4DevAI/kaapi-backend
Length of output: 131
🏁 Script executed:
wc -l backend/app/celery/celery_app.pyRepository: ProjectTech4DevAI/kaapi-backend
Length of output: 111
🏁 Script executed:
cat backend/app/celery/celery_app.py | grep -E "def |import"Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 386
🏁 Script executed:
rg "worker_process_init" --type py -B 2 -A 5Repository: ProjectTech4DevAI/kaapi-backend
Length of output: 1067
🏁 Script executed:
python3 << 'EOF'
# Check if object is the right type or if Any is better for **kwargs
# Standard Python typing conventions
import inspect
from typing import get_type_hints
# According to PEP 484 and Python typing best practices:
# When accepting **kwargs with a type hint:
# - **kwargs: Any is the standard approach (requires: from typing import Any)
# - **kwargs: object is valid but less idiomatic
# - No type hint is common but violates strict typing requirements
print("Python typing best practice for **kwargs:")
print("1. **kwargs: Any (most common and idiomatic)")
print("2. **kwargs: object (valid but less common)")
print("\nFor Celery signal handlers specifically:")
print("Signal handlers receive kwargs but often don't use them")
print("Using **_: Any or **_: object both indicate the handler ignores kwargs")
EOFRepository: ProjectTech4DevAI/kaapi-backend
Length of output: 374
Add a type hint for the variadic signal kwargs.
Line 13 leaves **_ untyped, which violates the repo typing rule for Python functions.
✅ Suggested fix
+from typing import Any
+
import logging
from celery import Celery
from celery.signals import worker_process_init
from kombu import Exchange, Queue
from app.core.config import settings
logger = logging.getLogger(__name__)
`@worker_process_init.connect`
-def warm_llm_modules(**_) -> None:
+def warm_llm_modules(**_: Any) -> None:As per coding guidelines, **/*.py: Always add type hints to all function parameters and return values in Python code. Use **_: Any to match the codebase pattern for signal handlers that intentionally ignore kwargs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@backend/app/celery/celery_app.py` at line 13, The function warm_llm_modules
currently uses an untyped variadic kwargs parameter (**_), which breaks the
repository typing rule; update the signature to use an explicit type hint for
ignored signal kwargs (change **_ to **_: Any) and ensure Any is imported from
typing if not already present, keeping the existing return annotation -> None
and the function name warm_llm_modules to locate the change.
2 participants
Summary
Target issue is #PLEASE_TYPE_ISSUE_NUMBER
Explain the motivation for making this change. What existing problem does the pull request solve?
Checklist
Before submitting a pull request, please ensure that you mark these task.
fastapi run --reload app/main.pyordocker compose upin the repository root and test.Notes
Please add here if any other information is required for the reviewer.
Summary by CodeRabbit