Repository navigation
PgTaskRegistry.list should paginate and filter in SQL #1352
Description
Priority: medium. Non-blocking performance follow-up to #1320, whose current implementation and documentation explicitly retain Python-side account-scoped filtering/pagination.
At reviewed head f50b2e2139e270aa2501ee5594ddd9478d6871c6, PgTaskRegistry.list selects every task row for the authenticated account, calls fetchall(), builds a complete record list, and then calls list_task_records to filter, order and page. The SQL account predicate preserves tenant isolation, but pagination={"max_results": 25} does not bound the number of rows fetched/materialized. Memory use and response latency therefore grow with the account's entire retained history, including result/progress/error payloads.
Source:
Review finding: #1320 (comment)
Current documented limitation/mitigation: https://github.com/adcontextprotocol/adcp-client-python/blob/f50b2e2139e270aa2501ee5594ddd9478d6871c6/docs/task-registry.md
Suggested acceptance:
- Push supported canonical filters, deterministic ordering and page bounds into parameterized SQL while retaining the account predicate before any row materialization.
- Preserve signed cursor account/query binding, task-ID tie breaking, current-state rather than frozen-snapshot semantics, legacy domain restrictions and existing invalid-filter/cursor responses.
- Fetch only a bounded page plus any lookahead needed to determine continuation; avoid loading terminal payloads for unrelated history.
- Cover parity with the memory implementation and real PostgreSQL using a large account history, multiple pages/sorts/filters, and another account. Verify that a small requested page bounds rows materialized, rather than testing only response length.
No security/isolation defect or failed existing correctness assertion is claimed. Until this follow-up lands, high-volume adopters can implement the optional ListableTaskRegistry protocol with SQL-native pagination as documented. The #1320 task-status repair should retain its existing bounded scope and normal CI/review gates.
The same inherited implementation is present in dependent #1327 at ad3b82478150e0657dd4947547c56e2b70189d33. Its review independently reports the same documented, non-blocking performance limit: #1327 (comment) . This is one shared SQL-pagination follow-up, not a separate lazy-pool/lifecycle defect.
Activity
bokelley commentedon Oct 3, 2026
Triage
Classification: Feature request (performance enhancement)
Bucket(s): client (no matching label found in repo — gap noted)
Status: deferred
What the experts said:
My take: This SQL-pagination work depends on the task-listing foundation being delivered in #1320. The issue author explicitly requests that #1320 retain its current bounded scope, making this a clean post-merge follow-up rather than a fold candidate. #1327 inherits the same Python-side pagination limit, so both prerequisites should land before this is implemented.
Blocked-on: #1320 — resurfaces on merge.
(Note: #1327 is the explicit dependent on top of #1320 and shares the same limitation; this issue covers the SQL-pagination layer for both once the chain is in.)
Triaged by Claude Code. Session: https://claude.ai/code/session_01Cd6fYQ1p3pzf695Dv6Nc5k
Generated by Claude Code
bokelley commentedon Oct 3, 2026
Triage
Classification: Feature request — performance enhancement (SQL-native pagination and filtering for
PgTaskRegistry.list)Bucket(s): client (decisioning layer)
Status: deferred
Milestone: (omitted — blocked on open prereqs)
What the experts said:
My take: The request is well-scoped and clearly non-blocking — the author explicitly asks that #1320 retain its existing bounded scope. Both prereq PRs are still open and actively iterating; this issue should resurface once they merge.
Blocked-on: #1320 — resurfaces on merge. (Also tracks the same SQL pagination gap in dependent #1327.)
Triaged by Claude Code. Session: https://claude.ai/code/session_01BHSiENRpA2yuXh5NxGwBHH
Generated by Claude Code