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…
cristim commentedon Nov 11, 2026
Claimed by claude-platform-2.
perf(history): push provider and account scope into the completed-his…
cristim commentedon Nov 11, 2026
Completed-history pushdown landed (Part of #632): provider, account and account scope are now pushed into the terminal-execution and purchase_history SQL reads as a superset prefilter (fail closed on an empty scope; nil scope adds no clause), the scope is loaded once per request instead of once per batch, and the Go checks still run on every row. Ordering and cursors are unchanged. Still open and tracked separately: #674 paging, #675 scope-aware summary totals, #676 Load more, #680 ordering inside the actionable class. Claim kept until the commit hash is posted here (claude-platform-2).
cristim commentedon Nov 11, 2026
Commit: 6e8ac00. Releasing my claim (claude-platform-2); the issue stays open for the items above.
cristim commentedon Nov 13, 2026
Claimed by claude-platform (coordinator priority list, 2026-11-13). Working this in a worktree; will post the landed commit or a blocker here.
cristim commentedon Nov 13, 2026
Premise check on origin/main (claude-platform): the title bug is already fixed. Actionable rows (pending, notified and similar) are fetched separately from terminal rows (2309fab), filters and account scope are pushed into the actionable query before the cap (df0de7e, internal/api/handler_history_actionable.go:12-30), and provider and account scope are pushed into completed-history reads (6e8ac00). Regression coverage: internal/api/handler_history_actionable_starvation_test.go:53 (pending not starved by newer terminal rows) and store tests in internal/config/store_postgres_executions_by_statuses_integration_test.go. Remaining items from the body, not yet verified: summary totals (handler_history_summary.go may still read the capped set), UI Load more, and date predicates (the date range is deliberately not pushed down for actionable rows, per #1685). Narrowing this issue to those three; the title bug is not reproducible on main.
cristim commentedon Nov 13, 2026
Closing: the fix is on main. Actionable rows are fetched separately from terminal rows (2309fab); filters and account scope are pushed into the actionable SQL (df0de7e); provider and account scope are pushed into the completed-history reads (6e8ac00). Regression test: TestHandler_getHistory_PendingNotStarvedByNewerTerminalRows in internal/api/handler_history_actionable_starvation_test.go. Sub-issues #674, #675, #676, #680 are closed. The date range for actionable rows is deliberately not pushed down (#1685).