Conversation
Greptile SummaryThis PR extends the model route condition system with two new filter fields —
Confidence Score: 4/5Safe to merge after fixing the frontend validation gap for empty The backend logic is solid — time-range parsing, overnight wrap-around, operator validation, and expression generation are all correct and well-tested. The one defect is on the frontend: when a user adds a frontend/src/features/models/components/models-association-dialog.tsx — the Important Files Changed
Sequence DiagramsequenceDiagram
participant Client
participant APIHandler
participant Orchestrator
participant ConditionEval as objects.Evaluate
participant XTime as xtime.DailyTimeWithin
Client->>APIHandler: POST /v1/... (sets req.APIFormat)
APIHandler->>Orchestrator: filterResolvedCandidatesForRequest(req)
Orchestrator->>Orchestrator: "requestFormat = req.APIFormat"
Orchestrator->>Orchestrator: "now = time.Now()"
loop For each association candidate
Orchestrator->>ConditionEval: "Evaluate(condition, {prompt_tokens, stream, request_format, now})"
alt daily_time condition
ConditionEval->>XTime: DailyTimeWithin(now, HH:mm-HH:mm)
XTime-->>ConditionEval: bool
else request_format condition
ConditionEval->>ConditionEval: "request_format == value"
end
ConditionEval-->>Orchestrator: bool
end
Orchestrator-->>APIHandler: filtered candidates
Reviews (2): Last reviewed commit: "feat: add advanced model route condition..." | Re-trigger Greptile |
| return (value?.groups || []).some((group) => hasConditionNodeData(group)); | ||
| } | ||
|
|
||
| function hasDailyTimeConditionNode(condition?: FilterBuilderCondition): boolean { | ||
| if (!condition) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Missing empty-string guard for
request_format value
When a user selects request_format as the condition field the value is initialised to '' (see filter-builder.tsx line 346). The validation block here only tests typeof condition.value !== 'string', which is false for an empty string, so the user can submit without ever choosing a format and the form will pass client-side Zod validation. The backend's validateStringEqualityLeaf rejects the empty string with an error, so the user sees a confusing server-side error instead of an inline UI message.
daily_time already handles this correctly because a second check tests the regex (which rejects ''). The request_format check needs an analogous non-empty guard.
Uh oh!
There was an error while loading. Please reload this page.