Repository navigation
Persist serving usage ledger for request-cost reconciliation - #1338
seonghobae wants to merge 1 commit into
Conversation
|
Warning Review limit reachedNext included review available in 17 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Local integration rehearsal at current heads: Adding #1313 |
|
Exact-head admission correction — Ready is review admission only. Fresh audit against base
This PR is moved to Draft/Proposed until the causal owner repair is present on a successor exact head and re-audited. Queued/pending work is neither an additional blocker nor passing evidence. No Close, force push, destructive rebase, manual rerun, synthetic status/approval, merge, auto-merge, or bypass was performed. |
Purpose
--state-dbretains workflow and decision records, but the serving CLI still constructs an in-memory cost ledger. A restart can therefore leave retained request evidence without the usage rows needed for cost reconciliation. This PR connects the existing SQL ledger store through an explicit serving-only--usage-ledger-dbpath.Contract
:memory:paths.Verification
--usage-ledger-db; after initial wiring, a regression caught distinct price-book instances; a file-mode assertion caught SQLite's default0644creation.-W error; 59 cost-ledger/boundary/CLI tests passed under the default warning policy.git diff --checkand CodeGraph sync passed.Research and scope
The primary reference for transaction and connection behavior is the Python sqlite3 manual; SQLite's atomic commit documentation describes the single-file durability model. Sigelman et al., Dapper, a Large-Scale Distributed Systems Tracing Infrastructure (Google Technical Report, 2010), https://research.google/pubs/dapper-a-large-scale-distributed-systems-tracing-infrastructure/ , motivates retaining request-level evidence across execution stages. Its PDF is linked rather than redistributed because redistribution permission was not established. This PR reuses the repository's SQL ledger implementation; it introduces no new estimator or billing policy.
Local proof is not a protected merge, hosted Linux acceptance, immutable release, or customer cost baseline. PR #1268 also edits the CLI serve path and currently has a textual merge conflict; integration should retain both changes when that PR is ready.