Repository navigation
fix(api/frontend): a 100-row history cap with no paging can hide pending approvals #248
Description
Summary
api.HistoryFilters carries no limit or offset, and the handler fetches with config.DefaultListLimit, which is 100, then applies the provider, account and date filters in memory afterwards. Rows beyond the first 100 are dropped before filtering, so the Approval Queue can under-report. The UI shows no truncation notice and offers no way to page.
Location
frontend/src/history.ts:340-345(filters carry no paging) at 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cdinternal/api/handler_history.go:145-149(fetch at the cap, then filter in Go)internal/config/constants.go:9(DefaultListLimit = 100)
Failure scenario
In a tenant with more than 100 non-completed executions, pending rows fall outside the first 100 and are discarded before the filters run. The Approval Queue renders "No pending approvals" while approvals are outstanding, and the summary cards under-report.
Evidence
const filters: api.HistoryFilters = {
start: (document.getElementById('history-start') as HTMLInputElement | null)?.value,
end: (document.getElementById('history-end') as HTMLInputElement | null)?.value,
provider,
account_ids: accountIDs
};Suggested fix
Return a truncated or total field from the API and render an explicit "showing the first 100 of N, narrow the date range" banner above both tables.
Found by the 2026-09-02 codebase audit, finding A12-029, reported by one reviewer and independently confirmed by a second. Full report: docs/audits/codebase-audit-2026-09-02.md.
Activity
cristim commentedon Oct 7, 2026
Claimed by cc-platform-w4.
Re-verified the issue's own suggested fix against
mainon 2026-10-07. It landed in PR #630 (merge18a6670d, merged 2026-10-06), which is the fix this issue asked for:HistoryResponsenow carriestruncated(bool),limitandexecutions_limit.internal/api/types.go, documented ininternal/api/openapi.yaml.internal/api/handler_history.go:88setsTruncatedwhen either fetch hit its cap.renderTruncationNotices()atfrontend/src/history.ts:394togglespurchases-truncation-noticeandhistory-truncation-notice(markup infrontend/src/index.html), cleared when a load fails (history.ts:281,:374).internal/api/handler_history_truncation_test.go(at cap, under cap, custom limit, execution cap, scoped user), plusfrontend/src/__tests__/history-truncation-notice.test.ts.So the silent-drop-without-a-hint half is done. The remaining half of the underlying defect (filters applied in Go after the cap, no paging, totals from the capped set) was deliberately split out of #630 and is tracked as #632 (rank 147, worker cc-platform-w3), which owns the SQL pushdown, paging and scope-aware totals.
cristim commentedon Oct 7, 2026
Correction to the above, after re-reading the framing: leaving this open rather than closing it.
PR #630 deliberately shipped as
Refs #248, notCloses #248, because the banner is only the half of this issue that was suggested as a fix; the failure scenario itself still reproduces. A pending approval can still fall off the first page, silently, behind older or other tenants' rows. #632 carries the rest (SQL pushdown, paging, scope-aware totals).Keeping this open as the umbrella for the history-cap defect so the p1 stays visible; #632 owns the implementation.
cristim commentedon Oct 8, 2026
Claim moved from cc-platform-w4 to cc-platform-w3 (fleet lead decision, 2026-10-08). #632 owns the implementation; this issue stays the umbrella. Reviewer: cc-cli-w2.
cristim commentedon Oct 16, 2026
@cristim the claim above from 2026-10-07 has had no linked PR or activity for over 7 days. Is it still active? If not, I can take this over. [claude-cc-impl]
cristim commentedon Oct 17, 2026
Owner decision (2026-10-17): the 2026-10-07 claim on this issue by an earlier agent session is released. That session has ended and no PR was opened. The platform implementation driver will pick it up in priority order.
cristim commentedon Oct 17, 2026
Checked against current main ([claude-cc-impl]). This issue's failure scenario, a pending approval silently hidden by the 100-row cap, is fixed:
truncatedand the UI render a banner (history.ts~:391-402).handler_history.go~:168-211).The remaining asks are tracked as their own p2 issues:
Nothing P1 remains here, so this umbrella can be closed by a maintainer. Labelling status/needs-info.