Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding IP address to device after deleting primary IP address fails due to caching #4647

Closed
lampwins opened this issue May 15, 2020 · 0 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@lampwins
Copy link
Contributor

Environment

  • Python version: 3.7
  • NetBox version: 2.8.4

Steps to Reproduce

  1. Disable any installed plugins by commenting out the PLUGINS setting in
    configuration.py.
  2. Create a device
  3. Create an interface on that device
  4. Add a new IP address to the interface and set it as the primary
  5. Delete the primary IP address
  6. Add a new IP address to the interface but do not set it as the primary

Expected Behavior

The new, non-primary address to be added to the interface and to be redirected back to the device page.

Observed Behavior

The IP address is created and assigned to the interface but the request fails, stating the old primary IP address cannot be found.

This is due to a caching invalidation bug that was uncovered when fixing #3304. The internals of the IPAddressForm.save() method makes use of the interface's parent attribute to access the primary_ip4/ip6 attributes. This issue is the access to that attribute crosses a FK relation which is not linked by cacheops for invalidation. This is very similar to the root cause described in #3304 and the fix is equally similar.

This highlights again that we need to make sure we are using prefetch_related() for all FK relationships to ensure invalidation linking for SET_NULL conditions.

@lampwins lampwins added status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application labels May 15, 2020
@lampwins lampwins self-assigned this May 15, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

1 participant