Repository navigation
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
Description
Follow-up from PR #630 (Refs #248: the API now signals truncation and the UI shows a banner). The real defect remains: handler_history.go fetches executions at DefaultListLimit and then filters in Go (status/surfaced-row filter, provider, account, date, and scope filtering), so a pending approval or failed execution can fall off the first page behind older rows or other tenants' rows, and the summary totals are computed from the capped set. Acceptance: push the surfaced-row, provider, account, date and scope predicates into the executions SQL (so the cap applies to rows that can actually be shown); add paging (offset/cursor or a next-page token) to the history endpoint and the UI ('Load more'); make the totals come from a COUNT/SUM with the same predicates (scope-aware: no cross-tenant counts); regression tests through HandleRequest and a store-level test for the SQL. Related: #248, #630, #593.
Activity
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 8, 2026
Scope decision (fleet lead, 2026-10-08): #632 is delivered as PR1 (pending-class statuses fetched separately so terminal rows cannot starve them, plus provider/account/date pushed to SQL as a superset prefilter) and PR2 (account-scope pushdown, fail closed, completed-history side too). Those satisfy "a pending approval is never silently hidden". Remaining asks are tracked separately: paging #674, scope-aware SQL totals #675, frontend Load more #676.
cristim commentedon Oct 8, 2026
PR1 scope note from the plan review: PR1 guarantees terminal rows cannot starve actionable rows. It does NOT claim to fix ordering inside the actionable class (far-future ramp steps sort first and can fill the 1000 cap); that residual is tracked in #680 and belongs to PR2 SQL.
fix(history): satisfy lint findings and pin the actionable cap by out…
cristim commentedon Oct 8, 2026
Follow-up for the two non-blocking review notes on PR #684 (banner cap wording, class listing error not setting truncated): #686
fix(history): fetch actionable executions separately so terminal rows…
IAmJSD commentedon Oct 26, 2026
Claiming: working on this
fix(history): apply plan_id in the filtered actionable read
IAmJSD commentedon Oct 26, 2026
Status note on the 2026-10-08 scope decision: #1464 (now
Refs #632, not closing) pushes the filters, the plan_id filter and the account scope into SQL for the actionable class (pending, notified, scheduled, approved, running, paused).The completed-history pushdown remains. The terminal-execution and purchase_history stream (
ListHistoryExecutionsPage/ListPurchaseHistoryPage) still applies provider, account and scope in Go. Since #1277 it walks keyset batches past hidden rows, so no row goes missing. The cost is extra batches for a scoped user whose rows are sparse. This issue stays open for that part: either a follow-up PR reusing #1464's predicate builder, or an owner decision to drop it.fix(history): push filters and account scope into the actionable exec…