Skip to content

issues list: 250-item cap is silent — add cursor pagination or a loud truncation indicator #54

Description

@jzillmann

Problem

linear issues list --limit 250 is a hard cap with no pagination and no truncation indicator. jq length on the JSON output returns 250 whether the real count is 250 or 5,000, so any aggregate built on it silently understates.

Concrete case: counting a ~800-issue Backlog state required manually partitioning by --created-after/--created-before date ranges and re-splitting every range that came back as exactly 250 — three rounds of bisection (one month alone needed two splits). Fragile, slow, and only works because creation dates happen to spread the data.

Verified at HEAD (e814332): no cursor/hasNextPage handling in internal/cli/issues.go.

Proposal

  1. Cursor pagination: a --cursor flag + nextCursor in JSON output (the Linear GraphQL API already paginates with pageInfo { hasNextPage, endCursor }), or an --all mode that auto-pages.
  2. Failing that, at minimum: when the API reports hasNextPage: true, print a warning to stderr and/or include "truncated": true in the JSON output so consumers can detect the cap instead of trusting a round 250.

Context

Hit while building a daily dev digest whose open-stock snapshot (actionable/backlog counts) depends on exact counts; it currently carries hand-rolled date-partition loops with "range hit cap" checks as a workaround.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions