Skip to content

Unbounded API responses on /rest/v1/root_cres and /rest/v1/all_cres #847

@shiwani42

Description

@shiwani42

Issue

What is the issue?

Two REST endpoints can return unbounded result sets, causing high memory usage and potential timeouts in production.

/rest/v1/root_cres has no pagination at all. It calls get_root_cres() which runs a full table scan with no limit and returns every root CRE in a single response. There is no way for clients to page through results.

/rest/v1/all_cres already has pagination but accepts any positive integer for per_page. Passing ?per_page=999999 fetches the entire dataset in one request, defeating pagination entirely. There is no MAX_PER_PAGE cap anywhere in the codebase.

Expected Behaviour

/rest/v1/root_cres should support page and per_page query parameters and return pagination metadata (page, total_pages) alongside data, consistent with how /rest/v1/all_cres already works.

/rest/v1/all_cres should enforce an upper bound on per_page so that a single request cannot retrieve the entire dataset regardless of what value is passed.

Actual Behaviour

/rest/v1/root_cres returns all root CREs in a single unbounded response with no pagination support.

/rest/v1/all_cres accepts ?per_page=999999 and returns the entire dataset in one response.

Steps to reproduce

GET /rest/v1/root_cres
# returns all root CREs, no page/total_pages in response

GET /rest/v1/all_cres?per_page=999999
# returns entire dataset in one response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions