Changes:
- test_streaming_download_real_image: Actually downloads GitHub logo PNG
- test_async_streaming_download_real_image: Async variant with real download
- Keep mock-based tests for large file validation (efficiency)
Real E2E tests validate:
- Images are actually downloaded from the internet via streaming
- Base64 encoding works correctly with real image data
- File integrity is maintained (PNG signature verified)
- No regression in normal image download functionality
Mock-based tests validate:
- Streaming stops at ~50MB for 100MB files (without downloading 100MB)
- Both sync and async code paths handle oversized files correctly
Changes:
- Extract DOWNLOAD_CHUNK_SIZE_BYTES constant (8KB) to replace magic numbers
- Add comprehensive E2E unit tests for streaming image download behavior:
* test_streaming_download_regular_image: Validates normal images download correctly
* test_async_streaming_download_regular_image: Async variant
* test_streaming_stops_for_large_image_without_content_length: Critical test
proving we stop downloading at ~50MB instead of downloading entire file
* test_async_streaming_stops_for_large_image_without_content_length: Async variant
Tests validate:
- No regression in normal image downloads (1-2MB images work)
- Streaming stops early for oversized files (downloads ~50MB of 100MB file)
- Both sync and async code paths work correctly
This ensures the streaming validation fix works as intended and prevents
downloading huge files entirely.
Previously, the image download handler would download the entire file
into memory before checking the size (when Content-Length header was
not provided). This could cause memory issues with very large files.
Changes:
- Implement streaming download using iter_bytes() in 8KB chunks
- Check cumulative size after each chunk during download
- Stop immediately when size exceeds MAX_IMAGE_URL_DOWNLOAD_SIZE_MB
- Add both sync and async versions of streaming validation
- Maintain efficient Content-Length header check for early rejection
This prevents downloading potentially huge files (e.g., petabyte-sized)
by stopping as soon as the limit is exceeded (~50MB + 8KB max).
Addresses feedback on PR #19257
Add documentation explaining the difference between model formats:
- `gemini/model` → Gemini API (simple API key)
- `vertex_ai/model` → Vertex AI (GCP credentials)
- `model` (no prefix) → defaults to Vertex AI
This addresses user confusion when models without prefix require
GCP authentication instead of simple API key auth.
Ref #8424
- Add google-cloud-aiplatform as optional dependency in pyproject.toml
- Add 'google' extra for easy installation: pip install litellm[google]
- Improve error messages when Google SDK is not installed to guide users
Fixes#5483
Replace independent auto-incrementing chart versioning with 1-1 sync
to LiteLLM version. This allows users to easily map Helm chart versions
to LiteLLM versions without needing to inspect appVersion.
Changes:
- Remove auto-increment logic that read from OCI registry
- Chart version now equals LiteLLM tag without 'v' prefix (v1.81.0 -> 1.81.0)
- appVersion equals full Docker tag (v1.81.0)
- Update both ghcr_deploy.yml and ghcr_helm_deploy.yml workflows
Before: helm chart 0.1.837 -> user has to guess LiteLLM version
After: helm chart 1.81.0 -> matches LiteLLM v1.81.0
References:
- https://codefresh.io/docs/docs/ci-cd-guides/helm-best-practices/