mirror of
https://github.com/BerriAI/litellm.git
synced 2026-09-14 23:21:35 +00:00
7041f5768f
An interactive oauth2 MCP server created with explicit endpoint URLs and no issuer served 400 "authorization url is not configured" from /authorize about a minute after creation, with the admin's endpoints intact in the row the whole time (#34985). Discovery wrote its trust-on-first-use issuer into the same column an admin writes, so the next registry build read the gateway's own output back as an admin pin, anchored the server to RFC 8414 section 3.3, and discarded the stored endpoint columns; one transient metadata fetch failure then had nothing to serve, and the reload fast path pinned the broken entry until an unrelated config write The core of the fix is a deletion. The gateway no longer writes discovery results anywhere: the OAuth columns and credentials.scopes carry admin intent alone, and everything discovery learns lives on the in-memory registry entry, as the existing carry-forward already assumes. With no gateway write there is no value whose provenance a later build can misread, so the accidental anchoring cannot be expressed Deleting the write cannot fix a row a released version already stamped, which still reads as pinned, so a one-time startup heal clears those stamps. The signal is necessarily a heuristic: updated_by records only the most recent writer and no audit trail says which field it touched. A row is therefore healed only on the full signature of the defect, which is discovery as the last writer plus an issuer plus at least one configured endpoint column that anchoring is actively discarding; rows with an issuer but no configured endpoints are left alone, since for them both paths resolve from the same upstream document. Every heal logs the cleared value so an admin who pinned deliberately can re-pin, and the heal records its own actor, which makes it idempotent The reload fast path exempts servers missing an endpoint their flow needs, so failed discovery retries on the normal reload cadence rather than waiting for a config write. Flow requirements are read through effective_oauth2_flow, the column-first shape-fallback judge every flow decision uses, so a legacy null-flow M2M row is classified exactly as the request path classifies it instead of re-discovering forever; a dcr_bridge server with no configured client needs its registration endpoint for the relay arm, and an entra_obo server needs a scope, both of which discovery can supply. Retries back off per server, doubling from one reload cadence to a fifteen-minute cap, so a permanently unresolvable server cannot re-run the RFC 9728 to 8414 chain and re-log its warning every cycle forever Deployments with store_model_in_db unset or false loaded MCP servers exactly once at startup, leaving that retry with no driver, so they now refresh the registry on the same reload interval. That job deliberately calls a reload-only entry point rather than the startup composite, keeping the one-time oauth2_flow backfill and issuer heal out of a recurring path Losing the persisted trust-on-first-use issuer also means the issuer column no longer changes underneath the OAuth token identity, so user tokens are purged only when an admin actually edits the server Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| public | ||
| scripts | ||
| src | ||
| tests | ||
| .env.development | ||
| .env.production | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| build_release_ui.sh | ||
| build_ui.sh | ||
| build_ui_custom_path.sh | ||
| CLAUDE.md | ||
| components.json | ||
| eslint-budgets.json | ||
| eslint-suppressions.json | ||
| eslint.config.mjs | ||
| knip.json | ||
| next.config.mjs | ||
| package-lock.json | ||
| package.json | ||
| postcss.config.js | ||
| README.md | ||
| tsconfig.json | ||
| tsconfig.tsbuildinfo | ||
| vitest.config.ts | ||
This is a Next.js project bootstrapped with create-next-app.
Getting Started
First, run the development server:
npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev
Open http://localhost:3000 with your browser to see the result.
You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.
This project uses next/font to automatically optimize and load Inter, a custom Google Font.
Learn More
To learn more about Next.js, take a look at the following resources:
- Next.js Documentation - learn about Next.js features and API.
- Learn Next.js - an interactive Next.js tutorial.
You can check out the Next.js GitHub repository - your feedback and contributions are welcome!
Deploy on Vercel
The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.
Check out our Next.js deployment documentation for more details.