[cristim]

Refs #248

Problem

GET /api/history fetches completed rows and non-completed executions at a cap (default 100) and applies the provider/account/date/scope filters afterwards, so rows beyond the cap are dropped silently. Pending approvals and summary totals can under-report with no UI hint.

Change

• HistoryResponse gains truncated (bool) and limit (int); openapi.yaml updated. The response was already an envelope, so this is additive and backward compatible.
• truncated is true when the completed fetch returned >= limit rows or the execution fetch returned >= DefaultListLimit rows.
• Frontend: banner above the approval queue and the history table (history.ts, index.html, types.ts).
• Tests: handler_history_truncation_test.go (at cap, under cap, custom limit, execution cap, scoped user). Mutating either >= to > fails them.

Scope interaction

The cap is applied BEFORE scope filtering (the store fetch is global), so a scoped user can lose their own rows behind other tenants' rows. truncated is judged on the raw fetch and exposed only as a boolean (no total), so no per-tenant counts leak; the scoped-user test asserts no total key. A scoped user may see the banner when the overflow is other tenants' rows. Summary totals are computed from the capped, filtered set, which the banner covers.

Decisions (alternatives)

• truncated + limit instead of total: a correct total needs COUNT queries with the same SQL filters on two tables, and the executions side is filtered in Go, so a total would need scope-aware counting. Alternative: add COUNT queries plus a total.
• Detect by len >= limit instead of fetching limit+1: avoids changing the store call arguments pinned by ~40 existing mock expectations. Cost: a false positive when exactly limit rows exist (documented in the field comment). Alternative: fetch limit+1 and trim.
• Not done: paging, or pushing provider/account/date filters into the executions SQL query (the real fix for pending approvals falling outside the first page); follow-up.

Verification

go test -race -short ./... , go vet ./... , go vet -tags integration ./internal/..., openapi tests pass; errcheck -blank, shadow, misspell clean on changed lines. Frontend jest test added but NOT run locally (no node_modules offline); CI will run it.

Why partial: paging and the executions-side SQL filtering remain open, so this is Refs, not Closes.

Review follow-up

• Store query now excludes clean completed executions (they only consumed the cap); the handler counts only surfaceable executions toward truncated.
• Response reports limit (completed rows, request-controlled) and executions_limit (fixed 100) separately; banner names both.
• Banner is cleared when a load fails.
• Scoped users in a busy deployment see the banner whenever other tenants' volume reaches the cap: a 1-bit global-volume signal, accepted but noisy for scoped users.
• Summary totals still come from the capped set; the banner says totals may be incomplete, the summary cards carry no label.
• Refs, not Closes: pending approvals can still fall off the first page. Paging and pushing provider/account/date filters into the executions SQL are tracked as fix(history): pending approvals can fall off the first page because filters are applied after the executions cap; add paging and push provider/account/date filters into the executions SQL #632.

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 11 billable files and costs up to $2.75.}

• Ask an admin to make reviews automatic

Open in CodeRabbit

Reviews can continue after your included limit without a manual trigger. An admin must approve usage-based billing.

Or wait 23 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available. Your 68 included PR review attempts over the past 7 days set your current allowance at 1 review per hour.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

• Configuration used: Repository: LeanerCloud/cloud-commitments-platform/.coderabbit.yaml
• Review profile: CHILL
• Plan: Essentials
• Run ID: 4519ab95-2a01-41f5-bc2d-b00a2ac75899

📥 Commits

Reviewing files that changed from the base of the PR and between fa10886 and 8e0033e.

📒 Files selected for processing (11)

• frontend/src/__tests__/history-truncation-notice.test.ts
• frontend/src/history.ts
• frontend/src/index.html
• frontend/src/types.ts
• internal/api/handler_history.go
• internal/api/handler_history_truncation_test.go
• internal/api/openapi.yaml
• internal/api/types.go
• internal/config/store_postgres.go
• internal/config/store_postgres_executions_by_statuses_integration_test.go
• internal/config/store_postgres_pgxmock_test.go

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

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