feat(approvals): server-side pagination + search pushdown for listRequests#1764
Merged
Conversation
…uests Closes the dangerous half of #1745: beyond the 500-row scan cap the inbox silently lost rows. listRequests gains q/limit/offset: - Free-text q pushes into the engine query as an $or of $contains terms over process_name / object_name / record_id / submitter_id / payload_json — the payload snapshot carries record titles, so titles match with no join and no enrichment round-trip. - The page window pushes into the engine (orderBy created_at desc) whenever the filter is fully pushable. approverId / status-array filters still post-filter in memory over the bounded scan and window after filtering — correct for personal queues, and the documented residual limit until the approver join-table follow-up (#1745). - New countRequests returns the unwindowed total, using engine count() when pushable and the bounded scan otherwise. - REST: GET /approvals/requests accepts q/limit/offset and returns {data, total} when paging (total costs a second query, so unpaged callers keep the old shape). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Closes the dangerous half of #1745 — beyond the 500-row scan cap the inbox silently lost rows. Console companion: objectstack-ai/objectui#1658 (merged).
qpushdown: free-text search becomes an$orof$contains(escaped-LIKE) terms overprocess_name/object_name/record_id/submitter_id/payload_json— the payload snapshot carries record titles, so business names match with no join.limit/offsetpush into the engine (orderBy created_at desc) whenever the filter is fully pushable.approverId/ status-array filters still post-filter their bounded scan and window in memory — correct for personal queues; the org-wide approver case is the documented residual until the approver join-table follow-up (perf(approvals): server-side pagination + pushdown filtering for listRequests #1745 stays open for that).countRequests: unwindowed total via enginecount()when pushable, bounded scan otherwise.GET /approvals/requestsacceptsq/limit/offset, returns{data, total}when paging; unpaged callers keep the old shape (no extra count query).Test plan
$or/$contains/offsetlimit=10&offset=0/10pages with zero overlap andtotal=31;q=Compliance→ 5/5 matches;status=recalled→ 2/2. Console: 56 rows → first page 50 + 「加载更多」 → 56/56 with the button gone; a debounced UI search for a title on an unloaded page returned the row (server search, not page filtering) ✅🤖 Generated with Claude Code