Feature Area
Backend API / Server
Problem Statement
I'm building an agent/ops tool that needs to page through a subject's full history. Currently, Statewave's GET /v1/timeline calls the repository layer with no limit or offset exposed to the caller, so it silently caps at 100 episodes and 100 memories with no way to page further and no signal that data was truncated. For long-lived subjects this means the timeline view is incomplete with no error or warning.
Proposed Solution
I'd like GET /v1/timeline to accept limit/offset query params (bounded, matching the pattern already used on /v1/subjects), threaded through to list_episodes_by_subject/list_memories_by_subject, plus a has_more flag per collection in the response so clients know to page.
API Design (if applicable)
GET /v1/timeline?subject_id=...&limit=100&offset=0
# response gains: "episodes_has_more": bool, "memories_has_more": bool
Alternatives Considered
Cursor-based pagination like /v1/receipts uses more scalable long-term but a bigger change than this endpoint needs right now; offset/limit matches the existing convention elsewhere.
Priority to You
Medium - Would be helpful
Additional Context
Any new limit/offset param must include ge/le bounds to satisfy the repo's CI invariant test (tests/test_route_limits_invariant.py).
Contribution: Leave unchecked filing this to source out as a community good-first-issue, not building it myself.
Contribution
Feature Area
Backend API / Server
Problem Statement
I'm building an agent/ops tool that needs to page through a subject's full history. Currently, Statewave's GET /v1/timeline calls the repository layer with no limit or offset exposed to the caller, so it silently caps at 100 episodes and 100 memories with no way to page further and no signal that data was truncated. For long-lived subjects this means the timeline view is incomplete with no error or warning.
Proposed Solution
I'd like GET /v1/timeline to accept limit/offset query params (bounded, matching the pattern already used on /v1/subjects), threaded through to list_episodes_by_subject/list_memories_by_subject, plus a has_more flag per collection in the response so clients know to page.
API Design (if applicable)
Alternatives Considered
Cursor-based pagination like /v1/receipts uses more scalable long-term but a bigger change than this endpoint needs right now; offset/limit matches the existing convention elsewhere.
Priority to You
Medium - Would be helpful
Additional Context
Any new limit/offset param must include ge/le bounds to satisfy the repo's CI invariant test (tests/test_route_limits_invariant.py).
Contribution: Leave unchecked filing this to source out as a community good-first-issue, not building it myself.
Contribution