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

Lazy loaded fields do not block save and cause unexpected modificiations #5382

New Issue
Closed
opened 2025-12-29 19:27:20 +01:00 by adam · 7 comments
adam commented 2025-12-29 19:27:20 +01:00
Owner
Copy Link

Originally created by @moonrail on GitHub (Sep 17, 2021).

Originally assigned to: @jeremystretch on GitHub.

NetBox version

v3.0.2

Python version

3.9

Steps to Reproduce

  1. Create e.g. a Device
  2. Edit the Device, save it as fast as possible (Edit -> directly to Save)
  3. Inspect error messages, that tell you, you should choose a Site, Device-Type and Device-Role

The time required to "wait" before saving anything is depending on the time lazy fields require to load their data.
So more data causes more time margin for this error to cause issues and increases its real life applicance.

Expected Behavior

A save without any changes should not omit data of the current instance of the model.

Observed Behavior

The POST is done before lazy loading is finished and seems to send null-values for the unfinished fields.
On NetBox instances with a lot of e.g. Sites, VLANs or else - anything that is loaded dynamically/loaded lazy, this issue becomes more and more apparent.

As you can see in the screenshot attached, the lazy loading of my local dev env (with nearly no data in it) took long enough to reproduce this error:

Screenshot_20210917_113220

Note: I have a simple CustomValidator with tenant required, therefore is Tenant also noted as required in screenshot.

Originally created by @moonrail on GitHub (Sep 17, 2021). Originally assigned to: @jeremystretch on GitHub. ### NetBox version v3.0.2 ### Python version 3.9 ### Steps to Reproduce 1. Create e.g. a Device 2. Edit the Device, save it as fast as possible (Edit -> directly to Save) 3. Inspect error messages, that tell you, you should choose a Site, Device-Type and Device-Role The time required to "wait" before saving anything is depending on the time lazy fields require to load their data. So more data causes more time margin for this error to cause issues and increases its real life applicance. ### Expected Behavior A save without any changes should not omit data of the current instance of the model. ### Observed Behavior The POST is done before lazy loading is finished and seems to send null-values for the unfinished fields. On NetBox instances with a lot of e.g. Sites, VLANs or else - anything that is loaded dynamically/loaded lazy, this issue becomes more and more apparent. As you can see in the screenshot attached, the lazy loading of my local dev env (with nearly no data in it) took long enough to reproduce this error: ![Screenshot_20210917_113220](https://user-images.githubusercontent.com/40096303/133761952-945fe1df-169b-4bdf-a56e-089d01947e0c.png) Note: I have a simple CustomValidator with tenant required, therefore is Tenant also noted as required in screenshot.
adam added the type: bugstatus: accepted labels 2025-12-29 19:27:20 +01:00
adam closed this issue 2025-12-29 19:27:20 +01:00
adam commented 2025-12-29 19:27:20 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 22, 2021):

loading time increase in 3.0.2 with lazy loading

This has nothing to do with the existing issue. Please open a new issue.

@DanSheps commented on GitHub (Sep 22, 2021): > loading time increase in 3.0.2 with lazy loading This has nothing to do with the existing issue. Please open a new issue.
adam commented 2025-12-29 19:27:21 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 22, 2021):

v3.0.2

This cannot be reproduced in v3.0.3.

Please upgrade and try to reproduce this. If you cannot please close the issue.

@DanSheps commented on GitHub (Sep 22, 2021): > v3.0.2 This cannot be reproduced in v3.0.3. Please upgrade and try to reproduce this. If you cannot please close the issue.
adam commented 2025-12-29 19:27:21 +01:00
Author
Owner
Copy Link

@moonrail commented on GitHub (Sep 22, 2021):

It's reproducable in 3.0.3.

Please see the following screenshot:
Screenshot_20210922_164909

  1. API-Requests for lazy loaded fields do not finish before "Save" is triggered and are aborted. Note that Requests to Tenants, Device-Types and Sites are not completed.
  2. POST is executed and returns visible errors. As Devices cannot be created without a Device-Type or Site, this indicates, that some information of the edited Device is not sent with the POST request on "Save". The Device has values for all errored fields, so it has to have something to do with the Edit-Form not being loaded fully. If I wait a little bit longer before saving, no such issue occurs.

Even if the regular user should most of the time not run into this issue, this has a lot of creep potential, where one single API request of a lazy loaded field is taking longer than the User needs and the edited object is nulling the before existing value, unbeknownest to the User.

@moonrail commented on GitHub (Sep 22, 2021): It's reproducable in 3.0.3. Please see the following screenshot: ![Screenshot_20210922_164909](https://user-images.githubusercontent.com/40096303/134366815-be853e5b-10ba-4476-a2ba-e44ad43afc34.png) 1. API-Requests for lazy loaded fields do not finish before "Save" is triggered and are aborted. Note that Requests to Tenants, Device-Types and Sites are not completed. 2. POST is executed and returns visible errors. As Devices cannot be created without a Device-Type or Site, this indicates, that some information of the edited Device is not sent with the POST request on "Save". The Device has values for all errored fields, so it has to have something to do with the Edit-Form not being loaded fully. If I wait a little bit longer before saving, no such issue occurs. Even if the regular user should most of the time not run into this issue, this has a lot of creep potential, where one single API request of a lazy loaded field is taking longer than the User needs and the edited object is nulling the before existing value, unbeknownest to the User.
adam commented 2025-12-29 19:27:21 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 23, 2021):

I was finally able to reproduce this. Maybe this is something @thatmattlove can look at, however I don't know if we can classify this as a bug as it looks like no data is saved.

@DanSheps commented on GitHub (Sep 23, 2021): I was finally able to reproduce this. Maybe this is something @thatmattlove can look at, however I don't know if we can classify this as a bug as it looks like no data is saved.
adam commented 2025-12-29 19:27:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 7, 2021):

Is there a reason we need to pre-populate the choices for all these fields (other than any single initially-selected choice), as opposed to populating them on-demand when the user expands a selection field?

@jeremystretch commented on GitHub (Oct 7, 2021): Is there a reason we need to pre-populate the choices for all these fields (other than any single initially-selected choice), as opposed to populating them on-demand when the user expands a selection field?
adam commented 2025-12-29 19:27:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Dec 7, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Dec 7, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 19:27:22 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Dec 7, 2021):

I think the solution is to block form submission until all fields are loaded.

@DanSheps commented on GitHub (Dec 7, 2021): I think the solution is to block form submission until all fields are loaded.
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#5382
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?