Replies: 4 comments
-
I created an experimental patch that solves this issue for me. Did not run the NetBox test suite so far. The basic idea is not to use the queue entry immediately before the last one and check whether it matches the object and request, but to find the last queue entry matching the object and request (if any) and updating that one.
|
Beta Was this translation helpful? Give feedback.
-
I found the time to run the NetBox tests now. Reference run without the above patch:
(all other tests pass) Test run with the patch:
(all other tests pass) In summary: 6 Tests are failing and one is erroring out, but they are behaving in exactly the same way whether the patch is in place or not. While this is not a totally valid test, it at least seems that the patch does not change the behaviour of NetBox in any way. As soon as I manage to get a successful test without the patch I'll know more. |
Beta Was this translation helpful? Give feedback.
-
Update: This is related to #6284. The fix for this issue only works if the |
Beta Was this translation helpful? Give feedback.
-
And another update: I created issue #15194 for it, and I have a prepared PR in my drawer. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
The problem is not that easy to reproduce. I'm working on the
netbox_dns
plugin and users are seeing a problem that they get multiple events (and, as a consequence, webhook executions) when an object is created or updated. I was able to track it down to howm2m_changed
events are handled by thehandle_changed_object()
function innetbox/extras/signals
.In my data model for DNS zones, there is a custom
save()
function that updates some other model instances after callingsuper().save()
. This leads multiple invocations ofhandle_changed_object()
, potentially queueing multiple object change events after the one for the zone object that is handled in the request. The zone object also has a many-to-many relationship with nameserver objects, so there is also potentially anm2m_changed
event causing another invocation ofhandle_changed_object()
for the zone. So far, so good.The problem is now that the invocation of
super().save()
causes an event for the zone object to be enqueued, then some other events for other objects are enqueued, and then them2m_changed
signal is handled and another event for the zone object is queued. Looking at the code ofhandle_changed_object()
, the interesting part is this:What it should do is obviously to check for an existing event for the same object in the queue, and if there is one, update that event instead of queuing a new one.
The problem is now that after the original change or create event for the zone object, other events were queued as well, so
queue[-1]
is not the earlier event for the same object we are looking for. As a result, theenqueue_object()
function is called, and so there are now two queue entries for the same object and the same request. This results in two webhook invocations, the first of which is obviously not getting correct data (the m2m fields are not updated yet).I'm pretty sure this is not limited to this specific case, but I'm not sure how to proceed from here. Depending on the logic that determines when the queue is actually worked on, an idea might be to replace the
queue[-1]
approach with some smarter logic that finds all queue entries with the same instance ID and request in the queue and then using the last one.Beta Was this translation helpful? Give feedback.
All reactions