mirror of
https://github.com/BerriAI/litellm.git
synced 2026-08-28 05:25:59 +00:00
4cbceb565b
Base UI's Select.Value resolves an option's label only when the root carries an `items` prop or the Value has a child. `resolveSelectedLabel` in @base-ui/react/internals/resolveValueLabel.js falls through every branch to `stringifyAsLabel(value)` otherwise, and `state.items` is written only from the root's `items` prop, so the `<SelectItem>` children rendered inside `<SelectContent>` never populate it. A self-closing `<SelectValue />` on a root without `items` therefore renders the raw value once something is selected. The placeholder branch still works, so the trigger looked right until the user picked an option and then showed `development` for Development, `LiteLLM_VerificationToken` for Keys, `all` for All Actions, and `24h` for Daily. Pass `items` at the 20 affected sites, using the array form the other 52 call sites already use. Where a literal option sat alongside mapped ones, build one array and map the options over it so the labels and `items` cannot drift. The record-map form is avoided deliberately: `items[value]` on an object literal reaches Object.prototype, so a dynamic value named `toString` would resolve to a function and React would throw on it. The array form matches with `.find` and has no prototype lookup, which matters where the values are user-supplied model groups, team ids and key aliases. Also replace the option lookup in CompetitorIntentConfiguration's test helper, which searched by text and clicked the last match. That match is now ambiguous because the trigger carries the label too, and the helper already flaked roughly one run in six before this change. |
||
|---|---|---|
| .. | ||
| litellm-dashboard | ||
| Dockerfile | ||
| nginx.conf | ||