DCIM Locations ordering issue

[duckw]

Deployment Type

Self-hosted

NetBox Version

v3.7.0

Python Version

3.9

Steps to Reproduce

I have not been able to reproduce this in another instance and need assistance in being able to provide sufficient information so that this can be remediated. This has been observed since v3.4 at least.

1. Create locations with the structure as shown below in the expected behaviour.
2. Go to the /dcim/locations/ page and confirm ordering is not correct.
3. Go into the incorrectly placed location and confirm the correct parent.

Expected Behavior

Locations created with this hierarchy.

ABC-B1
* ABC-B1-L1
* * ABC-B1-L1-SVR
* * ABC-B1-L1A
* * ABC-B1-L1B
* * ABC-B1-L1C
* ABC-B1-L2
* * ABC-B1-L2A
* * ABC-B1-L2B
* ABC-B1-L3
* * ABC-B1-L3A
* * ABC-B1-L3B
* ABC-B1-L4
* * ABC-B1-L4A
* * ABC-B1-L4B
* ABC-B1-L5
* * ABC-B1-L5A
* * ABC-B1-L5B
* ABC-B1-L6
* * ABC-B1-L6A
* * ABC-B1-L6B
* ABC-B1-L7
* * ABC-B1-L7A
* * ABC-B1-L7B

Observed Behavior

Locations are shown in /dcim/locations/ in this order: (note: ABC-B1-L2B, ABC-B1-L4B, ABC-B1-L7A are incorrect).

ABC-B1
* ABC-B1-L1
* * ABC-B1-L1-SVR
* * ABC-B1-L1A
* * ABC-B1-L1B
* * ABC-B1-L1C
* ABC-B1-L2
* * ABC-B1-L2A
* ABC-B1-L3
* * ABC-B1-L2B
* * ABC-B1-L3A
* * ABC-B1-L3B
* ABC-B1-L4
* * ABC-B1-L4A
* ABC-B1-L5
* * ABC-B1-L4B
* * ABC-B1-L5A
* * ABC-B1-L5B
* ABC-B1-L6
* * ABC-B1-L6A
* * ABC-B1-L6B
* * ABC-B1-L7A
* ABC-B1-L7
* * ABC-B1-L7B

[jeremystretch]

I have not been able to reproduce this in another instance and need assistance in being able to provide sufficient information so that this can be remediated.

I'm not sure what you're hoping someone can help you with here. If you haven't been able to reproduce it, how would anyone else?

[sleepinggenius2]

I've seen this happen before when the MPTT structure got messed up and it just required a rebuild to fix it. See #9196 for reference.

[duckw]

Thank you! The Location.objects.rebuild() corrected the issue.

Can anyone suggest if this is a good idea in raising a feature request to have Location.objects.rebuild() executed on startup or on a schedule? Although for me it took about 8 seconds to execute on 1300 locations, I could understand if this would not be desirable.

[jeremystretch]

No; the MPTT tree is rebuilt automatically as needed. The only time it's ever necessary to call rebuild() automatically is when dealing with corrupt data.

[jeffgdotorg]

No doubt this kind of thing can happen when MPTT goes wrong, but we still need clear and deterministic steps to reproduce the problem. Absent those steps, there's no work to be done, only a problem to be solved.

I'm converting this issue to a discussion so that you can seek help solving this problem in your environment. If in the course of that conversation you come up with repro steps, please do open a new bug issue!