fix(ui): route API Reference back to query-param page - #28726
Conversation
The path-based /ui/api-reference route was broken in practice — the page-local useProxySettings hook didn't match what the root page passes down. Remove api_ref from the migration maps (LEGACY_REDIRECTS in app/page.tsx, MIGRATED_PAGES in leftnav.tsx and (dashboard)/layout.tsx), point the leftnav item back at page="api_ref", and restore the api_ref render branch in the root page. The path-based page.tsx and the useProxySettings hook stay in place unchanged; only api_ref is moved back to query-param routing while the migration infrastructure is preserved for future page moves.
Greptile SummaryThis PR reverts the API Reference page from a path-based route (
Confidence Score: 5/5Safe to merge — the rollback is narrow and targeted, and the component's prop-driven design confirms the fix is complete. The four changed files all move in the same direction: restoring api_ref query-param rendering. APIReferenceView accepts proxySettings purely as a prop with no internal hook fallback, so passing it from the root fetch is sufficient to resolve the wrong base URL. Both the api_ref and hyphen-form api-reference query params are handled in the new if/else branch, covering transient bookmarks. The empty scaffolding maps compile fine and leave a clean extension point. No files require special attention.
|
| Filename | Overview |
|---|---|
| ui/litellm-dashboard/src/app/page.tsx | Empties LEGACY_REDIRECTS and adds an explicit if/else branch for both api_ref and api-reference query params, rendering APIReferenceView with proxySettings from the parent — correctly fixes the wrong base URL issue. |
| ui/litellm-dashboard/src/components/leftnav.tsx | Reverts menu item key/page from api-reference back to api_ref and empties MIGRATED_PAGES; comment updated to drop the stale LEGACY_REDIRECTS sync note. |
| ui/litellm-dashboard/src/app/(dashboard)/layout.tsx | Empties MIGRATED_PAGES; scaffolding retained for future page migrations. |
| ui/litellm-dashboard/src/components/page_metadata.ts | Key for API Reference page description reverted from api-reference to api_ref to match the restored query-param routing. |
Reviews (2): Last reviewed commit: "fix(ui): alias ?page=api-reference to ap..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| "use client"; | ||
|
|
||
| import APIReferenceView from "@/app/(dashboard)/api-reference/APIReferenceView"; | ||
| import SidebarProvider from "@/app/(dashboard)/components/SidebarProvider"; |
There was a problem hiding this comment.
The PR description's test plan has all three items as unchecked ([ ]), meaning there is no evidence that the fix was verified — including the primary user flow ("Click API Reference → lands on /ui?page=api_ref"). Per the team's review standards, a PR claiming to fix an issue should include evidence that the issue is resolved before merging.
Rule Used: What: Ensure that any PR claiming to fix an issue ... (source)
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Handles bookmarks of the hyphen-form query param that was live during the brief path-based migration window, so they render the working APIReferenceView instead of falling through to the default page.
|
@greptileai re review |
…itellm_revert_api_reference_path_routing
a8263cb
into
litellm_internal_staging
* fix(ui): route API Reference back to query-param page The path-based /ui/api-reference route was broken in practice — the page-local useProxySettings hook didn't match what the root page passes down. Remove api_ref from the migration maps (LEGACY_REDIRECTS in app/page.tsx, MIGRATED_PAGES in leftnav.tsx and (dashboard)/layout.tsx), point the leftnav item back at page="api_ref", and restore the api_ref render branch in the root page. The path-based page.tsx and the useProxySettings hook stay in place unchanged; only api_ref is moved back to query-param routing while the migration infrastructure is preserved for future page moves. * fix(ui): alias ?page=api-reference to api_ref branch Handles bookmarks of the hyphen-form query param that was live during the brief path-based migration window, so they render the working APIReferenceView instead of falling through to the default page.
2 participants
Summary
The API Reference page was migrated from query-param routing (
?page=api_ref) to a path-based route at/ui/api-reference. In practice the path-based variant resolvesproxySettingsvia a page-localuseProxySettingshook that doesn't match what the rootapp/page.tsxpasses everywhere else, so the page rendered with the wrong base URL / API doc base. Move API Reference back to the query-param render branch and leave the migration scaffolding (LEGACY_REDIRECTS,MIGRATED_PAGES) in place — empty — for future page migrations.What changed
leftnav.tsx— menu item back topage: "api_ref"; drop the entry fromMIGRATED_PAGES(map kept empty).app/page.tsx— restore thepage == "api_ref" ? <APIReferenceView .../> : ...render branch and theAPIReferenceViewimport; drop bothapi_refandapi-referenceentries fromLEGACY_REDIRECTS(map kept empty).(dashboard)/layout.tsx— drop the entry fromMIGRATED_PAGES(map kept empty).page_metadata.ts— key back toapi_ref.The
(dashboard)/api-reference/page.tsxroute and theuseProxySettingshook are left in place untouched; they're just no longer routed to by the sidebar.Test plan
/ui?page=api_refand renders the page with the correct base URL./ui/api-referencestill load (the route file remains; only sidebar routing changed).