bug: Ring and ledger count errors and coverage differently, cost reads slow down over time, and cost comments are stale
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 49/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- go
- Ambito
- backend, databases, performance
Direzione di ricerca
Start with core/cost/usage/usage.go and core/cost/ledger/writer.go to compare the error and priceability rules, then inspect the archive read and write paths in core/session/archive and ledger queries in core/cost/ledger. Add or update focused tests for zero-usage successful responses, excluded errors, archive rotation and reads, and past-day caching. Done means the ledger and ring agree, archive reads avoid repeatedly decoding growing segments, and stale comments match the code.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
The cost and session read paths have three problems. The ring (which serves the duration windows) and the ledger (which serves today/7d/month) count the same traffic by different rules. Two read paths get slower the longer the proxy runs. And several comments in core/cost describe code that has since changed. Line numbers are at ab5f01f26.
1. The ledger hides a coverage gap that the ring reports
- Ledger (
core/cost/ledger/writer.go:519-521): a request counts as priceable only ifr.Model != "" && r.Tokens > 0. - Ring (
core/cost/usage/usage.go:812-840): any successful response with a model counts as priceable, even with zero usage, and it is named inUnpricedBy.
Case: a truncated OpenAI-dialect stream returns 200, the model is set, and there is no usage block. inference-parser publishes no cost record for it. With 9 priced requests plus one of these:
window=todayshows 9/9, which looks fully priced.window=1hshows 9/10 and names the gap.
The ring's own comment (usage.go:821-825) calls the 9/9 result a bug it fixed. There is no ledger test for a successful response with zero usage.
2. The error rule is written twice, and only one copy was updated
countsAsError(usage.go:1279-1285) excludesErrorKindUpgradeDeclinedandErrorKindDestinationPrivate. The latter was added in ab5f01f26.- The ledger (
writer.go:514-516) still counts anyStatusCode >= 400 || Denied.
So a parsed inference request refused with 403 destination_private counts as an error on today but not on 1h.
Fix for 1 and 2: export usage.CountsAsError and a single "priceable" check, and call both from the ledger writer.
3. Archive segments never rotate, and every read decodes from the start
core/session/archive/archive.go: a segment closes only after 60 minutes idle (:736), at the open-writer cap, or on delete, clear, rename or a write failure. There is no size or event-count limit.
planPrunenever deletes an open segment (retention.go:54-63). A session busy all day therefore keeps one segment growing without limit, andmaxBytes(2 GiB) can stay exceeded.PageandEventdecode the segment from its first event up to the cursor, andEarliercallsPageonce per 500 events (read.go:44-81, 189-203). inference-router'swentTocallsEarlieron the request path withhistoryLimit = 2000. With 20k events in the segment, that is 4 page calls, each decompressing and decoding most of the segment, per request.
Fix: rotate in write after N events or M bytes, by calling closeWriter when s.w.info() passes the cap.
4. Every ledger query re-reads every day file in the window
core/cost/ledger/query.go:183-250 / store.go:493-530 open and fully decode each day file on every request, with no cache.
- agentop polls
todayevery minute and7d/monthevery 5 minutes (cmd/agentop/tui/spend.go:211-217). On the 31st,monthdecodes 31 files per poll, and past days almost never change. - The endpoint has no auth.
Fix: cache decoded past days keyed by (path, size, mtime). Only today's file needs re-reading.
5. Comments that contradict the code
core/cost/pricing/cost.go:20-25calls the accumulation wrap "an open defect", butCounts.Addsaturates (usage.go:349-405).cost.go:93-99saysMaxPlausibleTokenshas "NO IMPORTER ON THIS BRANCH". The ledger writer imports it (writer.go:288-324).cost.go:202-204saysplausibleTokenReportandRefusedTokenRequestsdon't exist. They do (usage.go:438, :122).ledger/writer.go:929-933saysDropped()has "No non-test caller today".sessionapi/usage.go:404calls it.
These read like notes from the middle of a PR stack. A reader trusting them would conclude that sums can still wrap and that the token bounds are not enforced.
Fix: delete or correct them.
Found by a code audit of main at ab5f01f26. Items 3 and 4 were verified by reading the code; the decode cost was not measured.
Assisted-By: Claude (Anthropic AI) [email protected]
- Lingua principale
- Go
- Stelle
- 21
- Fork
- 43
- Merge medio
- 13h 8m
- PR unite (30g)
- 267
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di rossoctl/cortex
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
UI shows costs for all sessions even when drilled into a sessionForse già presa @esnible l’ha presa 16 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
rossoctl/cortex#1116 · 2 commenti · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 Mezza giornata Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 Più di una settimana Idoneità per principianti 18/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di rossoctl/cortex
Issue simili
-
area:recipes event:contribfest format:human-first source:agent status:needs-triage type:recipe
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
cadence-workflow/cadence-ai-samples#140 ·
I maintainer di solito rispondono entro 1 giorno
-
ux
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
evcc-io/evcc#35605 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
project-setup
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
bug report
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
type:bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
nightgauge/nightgauge#2732 ·
I maintainer di solito rispondono entro 1 giorno