Repository navigation
PgTaskRegistry.list should paginate and filter in SQL #1352
Description
Activity
Triage
Classification: Feature request (performance enhancement)
Bucket(s): client (no matching label found in repo — gap noted)
Status: deferredWhat the experts said:
- Pre-classification: child-of-open-parent — body explicitly names open PR fix(decisioning): serve account-scoped task polling and listing #1320 ("follow-up to fix(decisioning): serve account-scoped task polling and listing #1320") and open PR feat(pg): lazily resolve decisioning stores on the serving loop #1327 shares the same documented limitation; expert consultation skipped per triage rules for this case.
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
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:
- Pre-classification short-circuited to Defer: this issue is explicitly a follow-up to open PR fix(decisioning): serve account-scoped task polling and listing #1320 and the same limitation is inherited by dependent open PR feat(pg): lazily resolve decisioning stores on the serving loop #1327. Expert consultation deferred until those PRs land.
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
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.listselects every task row for the authenticated account, callsfetchall(), builds a complete record list, and then callslist_task_recordsto filter, order and page. The SQL account predicate preserves tenant isolation, butpagination={"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:
adcp-client-python/src/adcp/decisioning/pg/task_registry.py
Line 521 in f50b2e2
Review finding: #1320 (comment)
Current documented limitation/mitigation: https://github.com/adcontextprotocol/adcp-client-python/blob/f50b2e2139e270aa2501ee5594ddd9478d6871c6/docs/task-registry.md
Suggested acceptance:
No security/isolation defect or failed existing correctness assertion is claimed. Until this follow-up lands, high-volume adopters can implement the optional
ListableTaskRegistryprotocol 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.