fix(models): resolve vision capability from modalities when explicit field is absent#1542
Conversation
Greptile SummaryThis PR introduces Confidence Score: 5/5Safe to merge — backward-compatible fix with no P0/P1 findings. All changes are additive and backward-compatible. The helper correctly preserves explicit No files require special attention. Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[User selects a model] --> B{resolveVision called}
B --> C{model.vision !== undefined?}
C -- Yes --> D[Return model.vision]
C -- No --> E{modalities?.input includes 'image'?}
E -- Yes --> F[Return true]
E -- No --> G[Return false]
D --> H[Set vision field in form]
F --> H
G --> H
subgraph models-action-dialog.tsx
I[handleModelIdChange] --> B
end
subgraph models-batch-create-dialog.tsx
J[handleModelIdChange] --> B
end
Reviews (3): Last reviewed commit: "fix(models): resolve vision capability f..." | Re-trigger Greptile |
5228188 to
100773f
Compare
There was a problem hiding this comment.
Code Review
This pull request introduces a resolveVision utility function to centralize the logic for determining vision support based on model properties or input modalities. This function is integrated into the model action and batch creation dialogs to ensure consistent behavior. Feedback suggests simplifying the resolveVision implementation using optional chaining to avoid unnecessary array creation and improve readability.
I am having trouble creating individual review comments. Click here to see my feedback.
frontend/src/features/models/data/providers.schema.ts (69-72)
The resolveVision function can be simplified using optional chaining and the nullish coalescing operator for better readability. This approach avoids creating an intermediate empty array when modalities or input is missing.
export function resolveVision(model: ProviderModel): boolean {
if (model.vision !== undefined) return model.vision;
return !!model.modalities?.input?.includes('image');
}
…field is absent - Add resolveVision() helper that infers vision=true from modalities.input containing 'image' when the explicit vision field is undefined (affects ~150 models in providers.json) - Fix batch-create-dialog: was incorrectly reading attachment instead of vision (attachment != vision capability) - Fix action-dialog: was reading raw .vision which is undefined for models that lack the explicit field
100773f to
8fe0202
Compare
Summary
Fix vision capability resolution for models that have image modality but lack explicit vision field. This ensures consistent vision detection across the codebase.
Spirit/Intent
Enable automatic vision capability detection from input modalities when explicit vision field is missing, preventing models with image support from being incorrectly marked as non-vision.
Key Changes
resolveVisionhelper in providers.schema.ts that checks explicit vision field first, then falls back to checking if 'image' is in input modalitiesresolveVisioninstead of direct vision field accessresolveVisioninstead of attachment-based fallbackRisks
Low risk - backward compatible change that preserves explicit vision field when present, only adds fallback behavior when absent.