-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Primary IP attribute of a device persists in cache after deleting an IP address #3304
Comments
An update to this, that after about 15min, the page now loads correctly.... |
I am unable to reproduce this, please provide reproducible steps. You can use https://master.netbox.dansheps.com to build test-cases if you need. |
Sure, Ill do some more testing over the next couple of days and revert. |
We had the same issue when deleting an IP Address from an interface on a device. It presets the option to confirm the removal, and then when the page refreshes, the above message is displayed. |
|
Please provide reproducible steps, starting from creating the device, otherwise we cannot action this as it cannot be reproduced |
In the future, this is a very relevant piece of information. However, I am still not able to reproduce this. Could you try reproducing this here: |
You are correct, I am unable to reproduce this on the demo website. Could it be related to a corrupt DB schema? If required, I could provide remote screen access. |
I just got the same error
The solution/workaround is to check the box to set the ip as the primary ip, then no error is returned |
Do you by any chance have any Custom Links defined? I notice from the backtrace:
If so, it's likely that your custom link URL is dependent on the device having a primary IP address, and is raising an exception if it does not. The workaround is to wrap a condition around your button text (not URL), so that it expands to empty string if the necessary field(s) are not present in the device:
|
I'm not able to replicate this on v2.6.4. |
I got into the similar error having custom links using {{obj.primary_ip}} even with existence check. I manage to reproduce it several times. Here you may see it at https://master.netbox.dansheps.com/dcim/devices/72/ . Steps to reproduce:
I have tested various jinja styles of checking the existence of Regards! |
What do you actually see when you do this? At that dansheps link I see the button with text "none", which is what I would expect. The "Text" must evaluate to exactly empty string to suppress the button and hence the expansion of the URL. If the text evaluates to any other string, then you will get a button with that text as that label, and the URL template will be expanded. And that seems to be what's happening here. So in real life, you'd do something like this:
so that the button is only displayed if |
I have prepared new device https://master.netbox.dansheps.com/dcim/devices/73/ you can delete the IP from that view to see the exact error. It is the same error as screenshoted from @InsaneSplash in the very first message in this issue. Note that in my case the URL is not using jinja, it was just for the test to see the state of the Anyway you'll see what I mean when press the delete trash button. |
Hm.. seems that 15 minute reset on netbox.dansheps.com is clearing the error on the device view, but you can still reproduce the bug and see immediately the error following my steps above. Can this be a caching error? |
I pressed the red Delete button for the device, and it was happy. What should I have done - delete the IP address from the interface? On device 72, I tried adding an IP address to interface "eth", and then deleting it again. All was fine. However I hadn't marked the address as primary. So then I added address "1.2.3.4/24" and checked Primary, and then I deleted it. Ah, then I got the error: Refreshing the page https://master.netbox.dansheps.com/dcim/devices/72/ I still see the error. This is about 12:25 UTC. If it goes after 15 minutes, then clearly it's some caching artefact. Thanks for making this reproducible! |
Exception was still present at 12:33 UTC, gone at 12:39 UTC. So to be clear, the steps to reproduce are:
EDIT: I had not created the custom link in my Netbox instance. After creating it, the problem occurs. |
It's perfectly repeatable on dansheps.com though (just done it again). |
Note: I first created a device (with an eth but no primary IP), and then added the Custom Link. Then browsing to the device I got the exception below, which at a glance seems consistent with the original one. So the problem appears to be:
|
Thanks @candlerb, appears to be caching related. Going to re-open this |
The root issue here is that the custom link template is accessing the device's Note: Since #3461 was implemented, a full exception no longer appears on the page: It is contained by disabling the rendered custom link button. (Hovering over the button reveals the exception message as a tooltip.) |
The fix for this is refreshingly simple :) The root cause has to do with the way cacheops handles The fix I discovered is to simply add the FK relation to the Knowing this, going forward we should probably make the best practice to ensure all FK relationships we intend to use in a given context are added to a prefetch. This also likely means we have other "weird" behavior related to this issue yet to be discovered. For instance, in this case, we had solved the symptom of custom links failing to render in #3461, but the issue still existed within the device view template itself, but it turns out the django templating engine suppresses these errors and simply returns an empty string (this was news to me). Also note that after fixing this in the course of testing, I uncovered another unrelated but similar caching issue. |
This isn't going to be possible under some circumstances, such as when rendering custom export templates. There's no way of knowing ahead of time to what related objects the author will make reference. |
Environment
Steps to Reproduce
Expected Behavior
Refresh showing the update device with the IP address removed.
Observed Behavior
An error occurs when trying to view the device at all times.
The text was updated successfully, but these errors were encountered: