[Bug]: Dashboard logs capped at 200 entries with no pagination — conversation filter and statistics incomplete

[jhste102lab]

Client or integration

OpenCodex dashboard

Area

Dashboard

Summary

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:

1. The conversation log filter only searches among the last 200 entries — older conversations are invisible
2. Statistics (usage, costs, tokens) derived from the dashboard only reflect the last 200 requests
3. There is no server-side pagination or offset/limit mechanism on GET /api/logs

Reproduction

1. Start ocx and send >200 requests through the proxy
2. Open the dashboard #logs tab
3. Observe that only the most recent 200 entries are visible
4. Apply the conversation filter — it can only find conversations among those 200 entries
5. 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.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[Wibias]

[shipping-github] Research review

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.ts GET /api/logs; tail clamp ~758–761.
Gaps: Did not verify how much of dropped in-memory history remains queryable via usage APIs.

[Wibias]

[shipping-github] Opened PR #784 to address this.

[Wibias]

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]

Closing as fixed by PR #784 (cd46a34): log buffer raised to 2,000 with limit/offset pagination.