from rest_framework.pagination import PageNumberPagination


class LifeyPagination(PageNumberPagination):
    """
    The default paginator for every list endpoint.

    PAGE_SIZE is 200 in settings, not DRF's 20: a Tasks page of 400 rows is
    plausible and the client reads a page's list whole — it sorts, filters and
    groups in the renderer. Every `features/<x>/data/api.js` unwraps
    `body.results ?? body`, so the envelope is what it already expects.

    ONE EXCEPTION, and it is a real one: `features/quick-capture/data/api.js`'s
    `listCaptures` does NOT unwrap — it maps `rows` directly. The captures
    viewset must therefore set `pagination_class = None` until that file is
    fixed, or the inbox comes back empty.

    -----------------------------------------------------------------------
    `page` IS TAKEN. THE PAGE-NUMBER PARAMETER IS `page_number`.
    -----------------------------------------------------------------------

    `?page=` means a WORKSPACE PAGE id here — `PageScopedViewSet.page_query_param`
    — and that is fixed by every `features/<x>/data/api.js` that already sends
    it. DRF's `PageNumberPagination` reads the same name for the page NUMBER,
    so with the default the two collide and the paginator is handed a page id.

    It does not fail quietly. A page id of 10 against a list that fits in one
    200-row page is `django.core.paginator.EmptyPage`, which DRF turns into
    **404 `{"detail": "Invalid page."}`** — so EVERY feature list 404s as soon
    as page ids pass single digits, on a server whose queryset was correct.
    That is what the first real cutover run hit: a freshly seeded account's
    Tasks page is id 10.

    Renaming the paginator's parameter is the half that is free to move: no
    client sends a page number, and the workspace-page name is a contract.
    """

    page_query_param = 'page_number'
    page_size_query_param = 'page_size'
    max_page_size = 1000