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

Pagination bug for VRF's in the web UI and API #1537

New Issue
Closed
opened 2025-12-29 16:32:47 +01:00 by adam · 1 comment
adam commented 2025-12-29 16:32:47 +01:00
Owner
Copy Link

Originally created by @taka-psba on GitHub (Feb 6, 2018).

Issue type

[ ] Feature request
[X] Bug report
[ ] Documentation

Environment

  • Python version: 2.7.5
  • NetBox version: 2.2.7

We have a lot of VRF's with the same name (don't ask :-() and if a group of such VRF's happens to span a page break, the web UI and API both can return the wrong thing when retrieving the list of VRF's. The problem appears to happen because the underlying SQL orders the VRF rows returned from the database by name only.

For example, if we have 5 VRF's called X, doing something like SELECT * FROM vrf ORDER BY name means that they must appear after all the W's and before all the Y's, but the ordering of the X's within themselves is undetermined. If these VRF's had RD's 1 through 5, and pagination was such that we want to show 3 of them on the first page and 2 on the second, for the first page, the database might return the X rows in ascending RD order, and we would see this:

    name   RD
    ====   ==
     W     ...
     X     1
     X     2
     X     3

On the second page, another SQL query is issued, and since the database is free to return the X's in any order it pleases, they could come back in descending RD order, and so we would see this:

    name   RD
    ====   ==
     X     2
     X     1
     Y     ...

IOTW, X-1 and X-2 appear twice, and X-4 and X-5 are missing. This also happens when calling the API.

Changing VRF.Meta.ordering to be ['name','rd'] clears the problem (presumably, this might be also happening elsewhere). I also checked the code for the v2.3-beta2 release you just pushed out, and it looks like the same thing will happen there as well.

I see here that sorting RD's is problematic, but in this particular case, it doesn't matter what the sort order of the VRF's is, just that it's stable across queries.

Originally created by @taka-psba on GitHub (Feb 6, 2018). ### Issue type [ ] Feature request <!-- An enhancement of existing functionality --> [X] Bug report <!-- Unexpected or erroneous behavior --> [ ] Documentation <!-- A modification to the documentation --> ### Environment * Python version: 2.7.5 * NetBox version: 2.2.7 We have a lot of VRF's with the same name (don't ask :-() and if a group of such VRF's happens to span a page break, the web UI and API both can return the wrong thing when retrieving the list of VRF's. The problem appears to happen because the underlying SQL orders the VRF rows returned from the database by name only. For example, if we have 5 VRF's called X, doing something like `SELECT * FROM vrf ORDER BY name` means that they must appear after all the W's and before all the Y's, but the ordering of the X's within themselves is undetermined. If these VRF's had RD's 1 through 5, and pagination was such that we want to show 3 of them on the first page and 2 on the second, for the first page, the database might return the X rows in ascending RD order, and we would see this: ``` name RD ==== == W ... X 1 X 2 X 3 ``` On the second page, another SQL query is issued, and since the database is free to return the X's in any order it pleases, they could come back in descending RD order, and so we would see this: ``` name RD ==== == X 2 X 1 Y ... ``` IOTW, X-1 and X-2 appear twice, and X-4 and X-5 are missing. This also happens when calling the API. Changing `VRF.Meta.ordering` to be `['name','rd']` clears the problem (presumably, this might be also happening elsewhere). I also checked the code for the v2.3-beta2 release you just pushed out, and it looks like the same thing will happen there as well. I see [here](https://github.com/digitalocean/netbox/issues/982) that sorting RD's is problematic, but in this particular case, it doesn't matter what the sort order of the VRF's is, just that it's stable across queries.
adam added the type: bugstatus: accepted labels 2025-12-29 16:32:47 +01:00
adam closed this issue 2025-12-29 16:32:47 +01:00
adam commented 2025-12-29 16:32:48 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Feb 7, 2018):

Yeah, the problem is that name isn't unique, so VRFs with the same name are ordered arbitrarily (and apparently inconsistently). We'll need a migration to add the rd field to the ordering declaration.

@jeremystretch commented on GitHub (Feb 7, 2018): Yeah, the problem is that `name` isn't unique, so VRFs with the same name are ordered arbitrarily (and apparently inconsistently). We'll need a migration to add the `rd` field to the ordering declaration.
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 status: accepted type: bug
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#1537
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?