Conversation
…g them The pod's structured-read interposer ignores body keys it does not read, so a System One body that named model "dgemma" (or carried images) and also carried audio or video came back as a confident answer about media the model never saw — verified against the live pod, where audio: 42 and video: 42 both answered 200 with the text-only token count. DiffusionGemma has no audio input at all, and its video path (vllm-project/vllm#57589) is not served by the interposer yet, so the honest answer at the door is a 400 dgemma_input naming the unsupported medium. The developer guide, OpenAPI description and request schema now say that images are dgemma's only media, and AGENTS.md records why: enabling video is a pod-side interposer change, not a Worker one. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review. 📝 WalkthroughWalkthroughThe DiffusionGemma route now refuses requests with non-null audio or video fields. Tests cover these refusals and confirm that an audio-only request without ChangesDiffusionGemma media input
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to The change rejects unsupported media for DiffusionGemma while preserving the described TypeSafe routing path; no merge-blocking risk is identified. Security Architecture ReviewSecurity architecture risk: 🔵 Low · up to The new refusal reduces the chance of a successful-looking answer to media the image-capable service did not process. It changes a public API response, but the reviewed path does not show expanded access or privileges. Retained concerns Security review detailsSecurity Blast Radius
Trust Boundaries and Controls
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
What
POST /v1/systemone bodies on the dgemma door (model "dgemma" named, or images present) that also carry
audio,audios,videoorvideosare now refused with 400dgemma_inputand a message naming the medium. The developer guide, the OpenAPI description and request schema, and AGENTS.md now state that images are dgemma's only media and why.Why
The pod's structured-read interposer silently drops keys it does not read. Verified against the live pod through production:
audio: 42andvideo: [wav data URL]both answered HTTP 200 with the text-only input token count — a confident answer about media the model never looked at, with no signal to the caller.The capability reality, checked at each layer:
diffusion_gemma.py)structured_server.py, vllm-project/vllm#57250)imagesonlyjev/diffusiongemmaAudio can never work on this model. Video can — the model declares the video modality and vllm-project/vllm#57589 fixed its multimodal path — but enabling it is a pod-side interposer change (build
video_urlparts), not a Worker one; until then refusing is the honest answer.Tests
New unit cases: all four media keys refused on both doors with nothing called upstream; audio without images and without naming dgemma still goes to TypeSafe to validate.
npm run typecheckclean,bun test823 pass / 0 fail.🤖 Generated with Claude Code
Summary by CodeRabbit
400 dgemma_inputresponse instead of being silently ignored. Image inputs remain supported; audio-only requests routed to other models are unaffected.