feat(usage): raise the management read entry cap from 200k to 500k by lidge-jun · Pull Request #1099 · lidge-jun/opencodex

lidge-jun · 2026-08-06T03:22:54Z

Summary

Raises MANAGEMENT_USAGE_MAX_ENTRIES in src/usage/log.ts from 200,000 to 500,000. The cap is a reader bound, not retention: for small-row logs it silently clipped what one management read could return inside the already-bounded 64 MiB byte window, hiding history from /api/usage without deleting it.
Updates the coupled regression test (tests/usage-log.test.ts) to the 500,001-row shape and refreshes its timing comment.
Devlog: devlog/_plan/260806_disposition_sweep/060_usage_cap_500k.md records the synthesis, the audit rounds, and the benchmarks (lands separately with the sweep unit's follow-up; the doc is committed on this branch).

Verification

Cap-binding worst-case benchmark (63.5 MiB densely packed with 629,205 tiny unique-requestId rows): 500,000 entries retained after parse-all-then-slice; read 1,436 ms + summarize 637 ms, ~897 MiB transient request-scoped RSS — inside the recorded acceptance threshold (≤3 s combined, ≤1.5 GiB transient).
Realistic-row benchmark: 96.7 MiB / 500k-row file — the 64 MiB byte window binds first (330,585 entries), so the entry cap is a secondary guard for realistic row sizes.
bun test tests/usage-log.test.ts tests/api-usage.test.ts tests/usage-rollup-merge.test.ts — 37 pass / 0 fail (cap test passes within STORE_BUDGET_MS).
Full suite: 9,065 pass / 0 fail / 8 skip (578 files). bun x tsc --noEmit clean.
Independent audit (terra): two FAIL rounds (memory-claim correction; cap-binding benchmark demanded) resolved to PASS. Confirmed no hunk collision with PR feat(usage): preserve usage history past the management read window with a daily rollup sidecar #1008's src/usage/log.ts changes.

Checklist

Scope stays focused and avoids unrelated cleanup.
Docs or release notes were updated when needed.
Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

Summary by CodeRabbit

New Features
- Increased the management usage log retention limit from 200,000 to 500,000 entries.
- Typical usage remains governed by the existing byte-size limit.
Documentation
- Added rollout guidance, benchmark results, acceptance criteria, and historical context for the expanded retention limit.

The cap is a reader bound, not retention: it silently clipped what one management read could return for small-row logs inside the already-bounded 64 MiB byte window. Benchmarked at the cap-binding worst case (63.5 MiB / 629k tiny rows, unique request ids): read 1.4s + summarize 0.6s, ~0.9 GiB transient RSS, request-scoped — inside the recorded acceptance threshold. Devlog: devlog/_plan/260806_disposition_sweep/060_usage_cap_500k.md

github-actions · 2026-08-06T03:23:06Z

✅ Deterministic PR hygiene checks passed.

coderabbitai · 2026-08-06T03:23:15Z

📝 Walkthrough

Walkthrough

The management usage log retention limit increases from 200,000 to 500,000 entries. The truncation test and usage-cap disposition plan update the corresponding expectations, timing note, benchmark criteria, and results.

Changes

Usage log retention cap

Layer / File(s)	Summary
Implement and validate the 500k entry cap `src/usage/log.ts:424`, `tests/usage-log.test.ts:129-138`, `devlog/_plan/260806_disposition_sweep/060_usage_cap_500k.md:1-51`	The reader retains up to 500,000 entries. The truncation test parses 500,001 rows and verifies retention of entries `1` through `500000`. The disposition plan records the implementation plan, benchmark criteria, and results.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

lidge-jun/opencodex#501: Both changes modify usage-log management reading and related tests.
lidge-jun/opencodex#829: Both changes adjust usage-log retention and truncation behavior.
lidge-jun/opencodex#1008: Both changes modify usage-log read-window behavior.

Suggested reviewers: wibias, ingwannu

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: raising the management usage read entry cap from 200,000 to 500,000.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

Create stacked PR
Commit on current branch

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch codex/usage-entry-cap-500k

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.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

coderabbitai

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/usage/log.ts`:
- Line 424: Validate production Bun memory headroom with a cap-binding read and
concurrent /api/usage requests, including the separate entries.slice() behavior
in readUsageSnapshotForManagement. If headroom is insufficient, update
parseUsageTextCooperatively or the aggregation path to retain only the newest
MANAGEMENT_USAGE_MAX_ENTRIES entries, or enforce an appropriate
deployment-specific lower limit.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 49ce273c-bbc2-4688-910e-fec7e42e28f3

📥 Commits

Reviewing files that changed from the base of the PR and between 7425855 and 9f6df99.

📒 Files selected for processing (3)

devlog/_plan/260806_disposition_sweep/060_usage_cap_500k.md
src/usage/log.ts
tests/usage-log.test.ts

coderabbitai · 2026-08-06T03:25:28Z

 const MANAGEMENT_USAGE_MAX_READ_BYTES = 64 * 1024 * 1024;
 const MANAGEMENT_USAGE_READ_CHUNK_BYTES = 1024 * 1024;
-const MANAGEMENT_USAGE_MAX_ENTRIES = 200_000;
+const MANAGEMENT_USAGE_MAX_ENTRIES = 500_000;


🚀 Performance & Scalability | 🔵 Trivial

Verify production memory headroom before release.

parseUsageTextCooperatively parses the complete byte-window input before it applies MANAGEMENT_USAGE_MAX_ENTRIES. The higher cap therefore allows more entries to remain in the snapshot and flow into /api/usage aggregation. The devlog reports approximately 897 MiB transient RSS for the cap-binding case at devlog/_plan/260806_disposition_sweep/060_usage_cap_500k.md:49. Identical reads share parsing, but readUsageSnapshotForManagement still returns a separate entries.slice() to each caller.

Run one cap-binding read and concurrent /api/usage requests under the production Bun memory limit. If the process lacks sufficient headroom, bound parsing or aggregation to the newest 500,000 entries, or enforce a deployment-specific lower limit.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/usage/log.ts` at line 424, Validate production Bun memory headroom with a cap-binding read and concurrent /api/usage requests, including the separate entries.slice() behavior in readUsageSnapshotForManagement. If headroom is insufficient, update parseUsageTextCooperatively or the aggregation path to retain only the newest MANAGEMENT_USAGE_MAX_ENTRIES entries, or enforce an appropriate deployment-specific lower limit.

lidge-jun requested review from Ingwannu and Wibias as code owners August 6, 2026 03:22

github-actions Bot added the enhancement New feature or request label Aug 6, 2026

coderabbitai Bot reviewed Aug 6, 2026

View reviewed changes

lidge-jun merged commit 791e0fb into dev Aug 6, 2026
23 checks passed

Navigation Menu

feat(usage): raise the management read entry cap from 200k to 500k - #1099

feat(usage): raise the management read entry cap from 200k to 500k#1099
lidge-jun merged 1 commit into
devfrom
codex/usage-entry-cap-500k

lidge-jun commented Aug 6, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

github-actions Bot commented Aug 6, 2026

Uh oh!

coderabbitai Bot commented Aug 6, 2026 •

edited

Loading

Walkthrough

Changes

Uh oh!

coderabbitai Bot left a comment

Uh oh!

coderabbitai Bot Aug 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

lidge-jun commented Aug 6, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Verification

Checklist

Summary by CodeRabbit

Uh oh!

github-actions Bot commented Aug 6, 2026

Uh oh!

coderabbitai Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

lidge-jun commented Aug 6, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Aug 6, 2026 •

edited

Loading