mirror of
https://github.com/BerriAI/litellm.git
synced 2026-10-09 03:18:44 +00:00
8d300d98d8
Classifying a turn is a read-modify-write over the session's stored state, and the read and the modify were happening on the request path while the write happened in the background flusher. Splitting one unit of work across two contexts is what produced all three findings from the last review round. The logging path now only stages the turn's facts; record_turn no longer takes a prisma client at all, so a database round trip in front of spend processing is not expressible. The flusher owns the whole read, fold and write per session, so a read that faults has no half-finished write to corrupt. It re-stages the turns through the same path a failed write already used, and the except branch that returned an empty state, then persisted it over real history, is gone rather than guarded. Folding at flush time also lets an interval's turns be sorted by start time before they are classified. Completion order is not start order, so two turns in flight together used to leave the earlier one read as a late arrival and dropped from every bucket; at arrival there is no later turn to compare against, so this was not fixable in the previous shape. StateUnavailable separates "the read failed" from "this session has no history", which were the same value before. Only the second one is writable. The staging ceiling counts turns rather than sessions, which is the quantity that actually bounds the memory a caller sending a fresh session id per request can make the proxy hold. Benchmark window dates are typed as dates on the route, so a malformed one is rejected by the framework instead of raising inside the aggregate, and an inverted range is a 400 instead of an empty dashboard that reads as no traffic |
||
|---|---|---|
| .. | ||
| 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.