4 commits

Author	SHA1	Message	Date
ryan-crabbe-berri	7ed25de120	fix(ui): allow any git host on the skills add form (LIT-4053) (#31652) ... * fix(ui): allow any git host on the skills add form (LIT-4053) The skills add form only accepted GitHub URLs: its URL parser bailed on any host that did not start with github.com, so GitLab, Bitbucket, and self-hosted repos (and any repo subfolder on them) were rejected before a request was ever sent. The backend already accepts arbitrary git hosts via its url and git-subdir sources, with no host allowlist, so this was a client-side restriction only. Generalize the parser into an exported, host-agnostic parseSkillSource: GitHub URLs keep their github / git-subdir shorthand, every other host is treated as a raw repo url, and an optional Subfolder path field turns any repo into a git-subdir source (url + path). When a pasted GitHub tree/blob URL already encodes a subfolder, the field is cleared and disabled so a contradictory source can never be submitted. The parser is hardened to match the backend contract: query strings and fragments are stripped, the host match is case-insensitive and drops a leading www., the extracted and field-entered subfolder paths are both validated against the same regex the server uses, a real file-extension allowlist (not "any dot") decides whether a trailing blob segment is a file, a branch-only tree URL falls back to the repo, non-GitHub URLs require at least an org/repo, and the suggested skill name is kebab-cased so it satisfies the name field's own rule. The git-subdir source is now handled in the display helpers (getSourceDisplayText, getSourceLink, formatInstallCommand), which previously showed it as "Unknown source" with no link. The submit path is fully typed (RegisterPluginRequest plus an AddPluginFormValues interface), removing the two prior any usages; as a result an author with an email but no name is dropped rather than sent, since the backend requires the author name. No backend changes. Tests cover the full host/subfolder matrix at the parser level plus form-submit assertions on the exact source payload. * refactor(ui): sync skill register types to the generated OpenAPI schema, surface backend errors Replace the hand-maintained, already-drifted API types for the skills add flow with the generated ones from schema.d.ts: PluginAuthor now aliases components["schemas"]["PluginAuthor"], the registration payload is a new SkillRegisterRequest (the generated RegisterPluginRequest envelope with source narrowed to our PluginSource union, since the backend types source as a loose string map, and version kept optional since the backend defaults it), and the dead, mismatched RegisterPluginResponse is deleted. registerClaudeCodePlugin's inline payload type (which was missing the git-subdir path field entirely) is replaced with SkillRegisterRequest, so the networking layer and the form can no longer drift from the backend. Error handling: the add-skill form swallowed the real failure and always showed "Failed to register skill". registerClaudeCodePlugin already derives the backend message and throws it, so the form now surfaces it ("Failed to register skill: <reason>"), and the networking helper falls back to the raw body / status when the error response is not JSON instead of throwing a JSON parse error. A regression test asserts the backend message reaches the user. * fix(ui): reject credentialed git URLs on the skills form A repo URL with embedded user-info (user:token@host) passed the raw-host parser and was stored verbatim as the skill source, which is served on the unauthenticated /public/skill_hub and marketplace.json feeds, leaking the credentials. Reject any host segment containing '@'. * fix(ui): validate skill repo URLs through one WHATWG URL gate Replace the ad-hoc string parsing (stripScheme / splitHost / manual scheme, @, ?# checks) with a single parseRepoUrl gate built on the URL parser, so every malformed/unsafe class is handled in one place and the URL stored on the public skill feeds is always canonical. It enforces https (rejecting http/ssh/git/file/javascript/data and protocol-relative //host), rejects embedded credentials (user:token@host, including userinfo-confusion like github.com@evil.com), rejects IP-literal hosts (loopback/private/metadata and obfuscated/IPv6 forms), and rebuilds the stored url from origin+pathname so query strings, fragments, and trailing slashes can never be published. The GitHub org/repo shorthand is now charset-validated like the other paths, so junk can't reach the stored repo. Closes both Veria findings (credentialed and http sources) plus the adversarial-review follow-ups, with regression tests for each class.	2026-06-30 10:29:49 -07:00
ryan-crabbe-berri	0e5aee1838	fix(ui): keep virtual-keys filters across delete and refresh (LIT-4080) (#31533) ... * fix(ui): keep virtual-keys filters across delete and refresh (LIT-4080) Filtering virtual keys by User ID and then deleting a key reset the filter to show all keys, and re-clicking Fetch did not re-apply it. The page ran two competing fetch paths: useKeys (React Query) fetched the page unfiltered while a separate useFilterLogic hook held its own filteredKeys list and, on any refresh, only re-applied Team and Organization client-side, silently dropping the User ID and Key Alias filters. Delete refreshed through the unfiltered useKeys path, so the filtered view collapsed back to everything VirtualKeysTable now owns its filter state and feeds every filter (team, organization, key alias, user id, key hash) straight into the useKeys options, so the filters are part of the React Query key. Any refetch or invalidation re-runs the same filtered query, which makes the reset-on-delete bug structurally impossible. Free-text inputs are debounced with @tanstack/react-pacer, sorting and pagination are server-side, and changing a filter or sort resets to page 1 Delete now invalidates keyKeys.lists() from key_info_view, matching the create path, instead of prop-drilling a refetch; the window "storage" refetch effect is removed. The dual-path useFilterLogic hook (and its test) are deleted Regression coverage: VirtualKeysTable threads an active User ID filter into the useKeys query and clears it on reset, useKeys encodes filter options in its query key so a filter change refetches, and key_info_view invalidates the keys list on delete * refactor(ui): simplify virtual-keys table data flow VirtualKeysTable now fetches its own teams and organizations via useOrganizations and the existing all-teams query instead of taking them as props, so the prop-drill through UserDashboard and the two page callers (page.tsx, ApiKeysDashboard) is gone along with their redundant organization state and fetch Filter state collapses from a useState plus a useDebouncedState mirror into a single source whose debounced copy is derived with useDebouncedValue, and one typed toKeyListFilters adapter maps it to the key/list query options. Behavior is unchanged; same 300ms debounce and the same reset timing The unused onSortChange/currentSort props and their sync effect are removed since no caller passed them, leaving sorting fully internal Adds a created_by_user alias-over-email regression test that fails if the display precedence is swapped * test(ui): add required last_active to useKeys mock fixtures The KeyResponse type requires last_active, so the typed mockKeys fixtures were missing it. Add it so the file type-checks cleanly. * chore(ui): ratchet lint budgets after virtual-keys refactor Deleting filter_logic.tsx and simplifying VirtualKeysTable lowered the no-explicit-any (2026 to 2016) and complexity (128 to 127) counts, so the eslint-metrics.json baseline was stale and failed the frontend-lint budget gate. Regenerate it, and drop the now-dead filter_logic.tsx suppression entry for the file this PR removed. * fix(ui): show a loading state for data-backed filter dropdowns The Team ID and Organization ID filters source their options from async hooks (teams / organizations). While that data was still loading the dropdowns rendered 'No results found', so they looked empty rather than loading. Add an opt-in loading flag to FilterOption that the searchable select surfaces as a spinner and a 'Loading...' empty state, and wire it from the teams and organizations query loading states. While loading, the filter no longer caches an empty initial-options list, so the real options appear once the data arrives.	2026-06-29 12:44:31 -07:00
ryan-crabbe-berri	234263fdda	fix(router): persist global retry_policy via /config/update (#29540) ... * fix(router): persist global retry_policy via /config/update (LIT-3152) The Admin UI Model Retry Settings tab POSTs {router_settings: {retry_policy: {...}}} to /config/update, but the field was dropped on two write-side layers so it never reached the router. UpdateRouterConfig did not declare retry_policy, so dict(exclude_none=True) stripped it before the DB upsert. And even when fed directly, Router.update_settings had no "retry_policy" entry in _allowed_settings, so the assignment was a silent no-op. The DB row stayed at {"model_group_alias": {}}, llm_router.retry_policy stayed None, and the UI fell back to defaultRetry = num_retries = 2 on refresh. Declare retry_policy on UpdateRouterConfig as a plain dict, and add a retry_policy branch to update_settings that coerces dict payloads to RetryPolicy before setattr, mirroring Router.__init__. get_settings already lists retry_policy, so reads work once writes land. * fix(router): guard retry_policy type in update_settings Mirror Router.__init__ semantics in update_settings: only assign retry_policy when it is None or a RetryPolicy (after dict coercion). Previously a non-dict, non-RetryPolicy value (e.g. a YAML typo like retry_policy: 5 flowing through /config/update) was stored verbatim, deferring the failure to request time in get_num_retries_from_retry_policy instead of being dropped at write time. * refactor(ui): harden Model Retry Settings flow and validate retry_policy at the boundary Types UpdateRouterConfig.retry_policy as RetryPolicy and model_group_retry_policy as Dict[str, RetryPolicy] so /config/update validates the payload and rejects malformed counts instead of silently persisting them; the apply path in update_settings keeps coercing the stored dict back to RetryPolicy Makes the Model Retry Settings tab the single owner of retry_policy and model_group_retry_policy so the generic Router Settings page no longer renders or writes them, replaces the fire-and-forget save with a react-query mutation that only shows the success toast after the write resolves, surfaces real errors, disables Save while in flight, and re-reads authoritative state on success, and sends both the global and per-group policies atomically so edits in the inactive scope are no longer dropped Decouples the retry-scope selector from the All Models filter and defaults it to Global, seeds the displayed default from num_retries (falling back to 2), and gives per-group rows real inherit semantics so an empty input shows the global value as a placeholder with a Reset control, keeping 0 ("no retries") distinct from inheriting the global value * fix(keys): align router_settings examples with typed RetryPolicy and resync UI artifacts model_group_retry_policy is now Dict[str, RetryPolicy], so the {"max_retries": 5} sample in the key-generate test and the /key/generate and /key/update docstrings no longer validate; they now use a valid {"gpt-4": {"RateLimitErrorRetries": 5}} shape. Regenerated eslint-metrics.json (no-explicit-any drifted 2027 -> 2026) and schema.d.ts (new RetryPolicy schema, retry_policy field, model_group_retry_policy value type) so the UI build and api-types-sync checks pass * test(router): pin retry_policy persistence end to end (LIT-3152) The existing retry_policy tests exercise UpdateRouterConfig and Router.update_settings in isolation, so they would all still pass if a regression flipped ConfigYAML.router_settings back to a loose dict or stopped add_deployment from applying the stored row. This drives the real handler chain an Admin UI save triggers: update_config writes the LiteLLM_Config row, the apply path forwards it to the live router, and get_config serializes it back, pinning retry_policy across persist, apply, and read-back. * fix(teams): use valid model_group_retry_policy example in router_settings docstring Same stale {"max_retries": 5} example the key endpoints carried; model_group_retry_policy maps a model group to a RetryPolicy, so the team /team/new and /team/update docs now show {"gpt-4": {"RateLimitErrorRetries": 5}}. Regenerated schema.d.ts to match. * fix(ui): load retry settings via deferred fetch to satisfy set-state-in-effect The Model Retry Settings effect called loadRetrySettings synchronously; eslint-plugin-react-hooks (react-hooks/set-state-in-effect) traces into it and flags the setState calls, failing frontend-lint. Split the loader into fetchRouterSettings + applyRouterSettings and run the fetch in an inline async IIFE with a cancellation flag, so state is applied in the post-await callback rather than on the effect's synchronous path. Behavior is unchanged and onSuccess still refreshes via loadRetrySettings. * fix(ui): match CI rendering of RateLimitError 429 docstring in generated schema gen:api run on a dev env (python 3.13 / newer fastapi) rendered the RateLimitError response description with 4-space indentation, but CI regenerates it with 8-space under its frozen python 3.12 toolchain, which is the canonical committed form. The Check UI API Types Sync job regenerates and diffs, so restore that block to the CI rendering; verified byte-identical to the pre-existing committed version. * fix(ui): pin RateLimitError 429 docstring to CI's frozen schema rendering Base #29619 regenerated schema.d.ts on a newer FastAPI that renders the RateLimitError response description at 4-space indent, but the Check UI API Types Sync job regenerates under the frozen python 3.12 toolchain, which renders 8-space. Merging base pulled in the 4-space form; restore the 8-space rendering so the generated types match what CI produces (verified byte-identical to the pre-#29619 committed form), which also corrects the base drift once this PR merges.	2026-06-28 00:20:20 +00:00
ryan-crabbe-berri	f2f6cacb19	feat(ui): track frontend lint counts in a committed snapshot (#31157) ... * feat(ui): track frontend lint counts in a committed snapshot Persist the eslint budget-rule counts (no-explicit-any, complexity, max-depth) to eslint-metrics.json so the trend is queryable straight from git history and can later feed a dashboard. A CI drift check regenerated from the same lint report keeps the snapshot honest, so a PR that shifts a count has to run npm run lint:metrics and commit it * fix(ui): harden lint-metrics drift check and eslint failure handling Make the drift comparison symmetric over the union of committed and actual keys so a phantom rule left in eslint-metrics.json (for example after a rule is dropped from eslint-budgets.json) is caught instead of silently passing. Only swallow eslint's lint-errors exit code in the generator and rethrow anything else, so a fatal eslint failure surfaces its real output rather than a confusing ENOENT on the missing report	2026-06-24 11:35:32 -07:00