You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Dashboard logs capped at 200 entries with no pagination — conversation filter and statistics incomplete #726
The in-memory request log ring buffer is hardcoded to MAX_LOG_SIZE = 200 (src/server/request-log.ts:129). Once 200 entries accumulate, the oldest entry is silently dropped. The Dashboard #logs tab fetches all logs with a single GET /api/logs call (no query parameters) and applies filters (conversation, surface) purely client-side. This means:
The conversation log filter only searches among the last 200 entries — older conversations are invisible
Statistics (usage, costs, tokens) derived from the dashboard only reflect the last 200 requests
There is no server-side pagination or offset/limit mechanism on GET /api/logs
Reproduction
Start ocx and send >200 requests through the proxy
Open the dashboard #logs tab
Observe that only the most recent 200 entries are visible
Apply the conversation filter — it can only find conversations among those 200 entries
Older request data is permanently lost from the dashboard view
Source references
MAX_LOG_SIZE = 200: src/server/request-log.ts:129
Ring buffer eviction: src/server/request-log.ts:222-224 (if (requestLog.length > MAX_LOG_SIZE) requestLog.shift())
Hydration cap from disk: src/server/request-log.ts:196-219 (reads max 200 from persisted usage log on startup)
tail parameter also capped at 200: src/server/request-log.ts:761
API endpoint has no pagination params: src/server/management/logs-usage-routes.ts:126-128 — returns all in-memory logs
Frontend fetches without query params, filters client-side: gui/dist/assets/index-cmds12BG.js
Expected behavior
Full request history should be accessible in the dashboard, either by increasing the in-memory buffer size significantly or adding server-side pagination
The conversation filter should be able to search across the full available history
GET /api/logs should support offset/limit (or cursor-based) pagination, and the frontend should lazy-load or paginate entries
Version
2.7.43
Operating system
Linux (WSL)
Checks
I searched existing issues and documentation.
I removed secrets, tokens, account details, request credentials, and personal data.
Claim: In-memory request log ring buffer is capped at 200 with no /api/logs pagination, so filters/stats only see recent traffic. Checked against: dev@be177ea5
Field
Finding
Still an issue on latest development?
yes
Exact issue
MAX_LOG_SIZE = 200 in src/server/request-log.ts; GET /api/logs returns the in-memory set; tail also capped at 200
Fixed on development?
no
Open PR covering this?
none
Duplicate of?
none (related historical #500 was usage.jsonl parse cost, different)
Security relevance
none — n/a (raising retention has privacy/storage tradeoffs but not a vuln class)
Priority
middle — real dashboard limitation after moderate traffic; data still may exist in usage persistence depending on path
Verdict
Needs fix on development
Evidence:src/server/request-log.ts:129 and eviction ~222–224; logs-usage-routes.tsGET /api/logs; tail clamp ~758–761. Gaps: Did not verify how much of dropped in-memory history remains queryable via usage APIs.
Thanks @jhste102lab — fixed by PR #784 (cd46a34): the in-memory request log buffer is now 2,000 entries with newest-first limit/offset pagination and a filtered otal, so dashboard conversation filters and stats are no longer truncated at 200.
Activity
github-actions commentedon Jul 30, 2026
Automated translation bookkeeping — detected language: unknown.
Wibias commentedon Jul 30, 2026
[shipping-github] Research review
Claim: In-memory request log ring buffer is capped at 200 with no
/api/logspagination, so filters/stats only see recent traffic.Checked against: dev@be177ea5
MAX_LOG_SIZE = 200insrc/server/request-log.ts;GET /api/logsreturns the in-memory set;tailalso capped at 200Evidence:
src/server/request-log.ts:129and eviction ~222–224;logs-usage-routes.tsGET /api/logs;tailclamp ~758–761.Gaps: Did not verify how much of dropped in-memory history remains queryable via usage APIs.
Wibias commentedon Jul 30, 2026
[shipping-github] Opened PR #784 to address this.
Wibias commentedon Jul 31, 2026
Thanks @jhste102lab — fixed by PR #784 (cd46a34): the in-memory request log buffer is now 2,000 entries with newest-first limit/offset pagination and a filtered otal, so dashboard conversation filters and stats are no longer truncated at 200.
Wibias commentedon Jul 31, 2026
Closing as fixed by PR #784 (cd46a34): log buffer raised to 2,000 with limit/offset pagination.
fix: address issue lidge-jun#726
test(logs): expect /api/logs envelope in lidge-jun#725 timezone suite