makeplane / makeplane/plane

Public API: project work-items list ignores ?page= and never terminates pagination (v1.3.0)

Open
#9,340 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
59.6k
Forks
5.8k
Avg merge
1d 22h
Merged PRs (30d)
49

Description

Describe the bug

On the public REST API, the project work-items list endpoint does not paginate: the ?page= query parameter is ignored and every page returns the same first per_page results, while the pagination metadata (total_pages, next_page_results) advertises that more pages exist. There is also no usable next link/cursor in the response to advance with.

As a result, an API consumer cannot retrieve any work item beyond the first page, and a client that follows next_page_results will loop forever (re-fetching the identical first page), because next_page_results is always true.

Endpoint
GET /api/v1/workspaces/{workspace_slug}/projects/{project_id}/work-items/?per_page=100&page=N

(authenticated with an X-API-Key)

Steps to reproduce

In a project with more than per_page work items (e.g. ~290 items, per_page=100), request several page numbers and compare the returned item IDs:

page results len count total_pages next_page_results next IDs vs page 1
1 100 100 3 true (none)
2 100 100 3 true (none) 100/100 identical
3 100 100 3 true (none) 100/100 identical
4 100 100 3 true (none) 100/100 identical
50 100 100 3 true (none) 100/100 identical
200 100 100 3 true (none) 100/100 identical

Every page number — including page=200, far past total_pages=3 — returns the exact same 100 rows, with next_page_results: true and no terminating signal.

Expected behavior

Either:

  • ?page=N should return the Nth page of results (distinct items), and next_page_results/total_pages should reflect the true end (so page 4+ returns an empty/short page or 404), or
  • if the endpoint is cursor-paginated only, it should provide a usable next cursor/link and stop advertising next_page_results: true once the final page is reached — and ideally document that ?page= is not supported.

Currently neither holds: ?page= is silently ignored, next_page_results never becomes false, and no next cursor is returned, so there is no correct way to page through results.

Impact

The paginated list API is effectively capped at the first per_page items. Any integration that enumerates work items (sync, export, reporting, automation) either silently misses everything past page 1 or hangs in an infinite pagination loop.

Environment
  • Deployment: self-hosted (Docker, via Coolify)
  • APP_RELEASE: v1.3.0 (makeplane/plane-backend:v1.3.0, makeplane/plane-frontend:v1.3.0)
  • Access: public REST API (/api/v1) with a workspace API token

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing GET /api/v1/workspaces/{workspace_slug}/projects/{project_id}/work-items/?per_page=100&page=N and trace the public REST API work-items list entry point. Compare results and pagination metadata across page values, then verify that distinct pages are returned and pagination stops at the final page.

Written by the indexing model from the issue text.

Assessment

Tech stack
django, python
Domain
api, backend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
67/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.