starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

[PR #18151] [MERGED] Fixes: #18150 - Get pagination limit with default 0 #15282

New Issue
Closed
opened 2025-12-30 00:21:03 +01:00 by adam · 0 comments
adam commented 2025-12-30 00:21:03 +01:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/netbox-community/netbox/pull/18151
Author: @bctiemann
Created: 12/3/2024
Status: ✅ Merged
Merged: 12/12/2024
Merged by: @jeremystretch

Base: develop ← Head: 18150-get-limit-with-default-0

📝 Commits (9)

  • c3d38ea Wait until job1 is scheduled before enqueueing job2
  • af2768a Clamp limit=0 to default_limit
  • 647c7c9 Handle unspecified limit explicitly so as to return min(PAGINATE_COUNT, MAX_PAGE_SIZE)
  • 020386f Revert original min()
  • acecb3a Coerce MAX_PAGE_SIZE to be at least PAGINATE_COUNT
  • 5dd93c0 Raise ImproperlyConfigured error if MAX_PAGE_SIZE < PAGINATE_COUNT
  • 5087a11 Revert test behavior
  • b141f8c Revert "Revert test behavior"
  • 14d6fd1 Revert "Raise ImproperlyConfigured error if MAX_PAGE_SIZE < PAGINATE_COUNT"

📊 Changes

2 files changed (+19 additions, -4 deletions)

View changed files

📝 netbox/netbox/api/pagination.py (+3 -1)
📝 netbox/utilities/tests/test_api.py (+16 -3)

📄 Description

Fixes: #18150

If limit is not specified in an API list view, the value raises a KeyError which is silently swallowed without processing MAX_PAGE_SIZE, leading to inconsistent pagination results. This change uses .get() with a default of 0 to ensure no exception is raised and the configured page limit is enforced.

Specifically: in our current behavior, we have these scenarios:

    defaults:
    PAGINATE_COUNT: 50
    MAX_PAGE_SIZE: 1000

    limit=0 => MAX_PAGE_SIZE (this can functionally be "unlimited" if MAX_PAGE_SIZE is set very high)
    limit=n => min(n, MAX_PAGE_SIZE)
    limit omitted => PAGINATE_COUNT

With this behavior, if a script hits a list endpoint with no limit, the next URL will be paginated by PAGINATE_COUNT; but if the script follows that link, the next page will use the limit=n case, and the overall page count and next and previous links are paginated by MAX_PAGE_SIZE rather than PAGINATE_COUNT, which would re-flow all the pages and potentially lead to miscounts or other unexpected script behavior. This can be worked around by a script always specifying a limit, but it seems more sensible for omitting limit to be consistent with limit=0.

After this change:

    limit=0 (or omitted) => min(PAGINATE_COUNT, MAX_PAGE_SIZE)
    limit=n => min(n, MAX_PAGE_SIZE)
    No way to get "unlimited" except by setting both limit and MAX_PAGE_SIZE very high

Open question(s):

  • Should we support a use case for "unlimited" results, and if so, how? Is the above suggestion good?
  • Is limit=0 being a synonym for "unlimited" more intuitive than having limit=0 behave the same as omitting limit?
  • Will limit=0 being interpreted as limit=50 be surprising to the user?

NOTE: The fix has changed; leaving the above to preserve the discussion history.

This fix maintains the existing (separate) behaviors of limit=0 and limit omitted. However, it changes the "limit omitted" case to return min(PAGINATE_COUNT, MAX_PAGE_SIZE), i.e. to ensure MAX_PAGE_SIZE is enforced.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/netbox-community/netbox/pull/18151 **Author:** [@bctiemann](https://github.com/bctiemann) **Created:** 12/3/2024 **Status:** ✅ Merged **Merged:** 12/12/2024 **Merged by:** [@jeremystretch](https://github.com/jeremystretch) **Base:** `develop` ← **Head:** `18150-get-limit-with-default-0` --- ### 📝 Commits (9) - [`c3d38ea`](https://github.com/netbox-community/netbox/commit/c3d38ea9c18f6b211c10f630bc48bc20bd2c7a4f) Wait until job1 is scheduled before enqueueing job2 - [`af2768a`](https://github.com/netbox-community/netbox/commit/af2768aa3dcf59c8c6f6557df5b9327a6934f83d) Clamp limit=0 to default_limit - [`647c7c9`](https://github.com/netbox-community/netbox/commit/647c7c9579b277d9338d17c37b4daab1e027d54a) Handle unspecified limit explicitly so as to return min(PAGINATE_COUNT, MAX_PAGE_SIZE) - [`020386f`](https://github.com/netbox-community/netbox/commit/020386f8a143126aee01b5481fbedb9bbc9efc33) Revert original min() - [`acecb3a`](https://github.com/netbox-community/netbox/commit/acecb3a81c6784b5cb90afc2da5f6b57e0e09c99) Coerce MAX_PAGE_SIZE to be at least PAGINATE_COUNT - [`5dd93c0`](https://github.com/netbox-community/netbox/commit/5dd93c096d64292a034d1e1f79a5955b63f7f7f1) Raise ImproperlyConfigured error if MAX_PAGE_SIZE < PAGINATE_COUNT - [`5087a11`](https://github.com/netbox-community/netbox/commit/5087a1111a9ba4126a7ea492bfaae5f6e71957cb) Revert test behavior - [`b141f8c`](https://github.com/netbox-community/netbox/commit/b141f8c2d8656cdc7052f72383654a97f22ff6e2) Revert "Revert test behavior" - [`14d6fd1`](https://github.com/netbox-community/netbox/commit/14d6fd1bc1d3c178acf796bde918f70953f00f11) Revert "Raise ImproperlyConfigured error if MAX_PAGE_SIZE < PAGINATE_COUNT" ### 📊 Changes **2 files changed** (+19 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `netbox/netbox/api/pagination.py` (+3 -1) 📝 `netbox/utilities/tests/test_api.py` (+16 -3) </details> ### 📄 Description ### Fixes: #18150 If `limit` is not specified in an API list view, the value raises a `KeyError` which is silently swallowed without processing `MAX_PAGE_SIZE`, leading to inconsistent pagination results. This change uses `.get()` with a default of 0 to ensure no exception is raised and the configured page limit is enforced. Specifically: in our current behavior, we have these scenarios: ``` defaults: PAGINATE_COUNT: 50 MAX_PAGE_SIZE: 1000 limit=0 => MAX_PAGE_SIZE (this can functionally be "unlimited" if MAX_PAGE_SIZE is set very high) limit=n => min(n, MAX_PAGE_SIZE) limit omitted => PAGINATE_COUNT ``` With this behavior, if a script hits a list endpoint with no `limit`, the `next` URL will be paginated by `PAGINATE_COUNT`; but if the script follows that link, the next page will use the `limit=n` case, and the overall page count and `next` and `previous` links are paginated by `MAX_PAGE_SIZE` rather than `PAGINATE_COUNT`, which would re-flow all the pages and potentially lead to miscounts or other unexpected script behavior. This can be worked around by a script always specifying a `limit`, but it seems more sensible for omitting `limit` to be consistent with `limit=0`. After this change: ``` limit=0 (or omitted) => min(PAGINATE_COUNT, MAX_PAGE_SIZE) limit=n => min(n, MAX_PAGE_SIZE) No way to get "unlimited" except by setting both limit and MAX_PAGE_SIZE very high ``` Open question(s): - Should we support a use case for "unlimited" results, and if so, how? Is the above suggestion good? - Is `limit=0` being a synonym for "unlimited" more intuitive than having `limit=0` behave the same as omitting `limit`? - Will `limit=0` being interpreted as `limit=50` be surprising to the user? **NOTE:** The fix has changed; leaving the above to preserve the discussion history. This fix maintains the existing (separate) behaviors of `limit=0` and `limit` omitted. However, it changes the "`limit` omitted" case to return `min(PAGINATE_COUNT, MAX_PAGE_SIZE)`, i.e. to ensure `MAX_PAGE_SIZE` is enforced. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
adam added the pull-request label 2025-12-30 00:21:03 +01:00
adam closed this issue 2025-12-30 00:21:04 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#15282
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?