Unable to merge a branch with plugin data #56
Comments
I can't make any sense of it yet - this time it was the IP address that triggered the error. Changes look pretty simple: 
|
|
headers for the import name,nameservers,soa_rname,soa_mname |
|
Error confirmed: |
|
Post change data for fail: |
|
LOG SQL Query Manually editting the SQL query to run against the branch schema works as expected (returns an entry) |
|
I can see where that comes from. Replaying the change log creates the zone, which automatically creates the NS record, and then the branching plugin tries to replay the action adding the NS record as well - which would result in a duplicate record, and hence is refused. Which is pretty exactly what I meant yesterday :-/ |
I think so too - certainly for the validation errors. However I don't think we've explained this yet ?
|
|
The only explanation I have is that branching tries to create records for a zone when the create operation for the zone has not been replayed yet. I would expect the change log to have the operations in the order they have been originally executed, i.e. first the zone.create() and then the record.create(). But I also remember one of the wierdest bugs in NetBox I've found so far: netbox-community/netbox#15194 I'm not sure there is a relation between the two, but basically the fix for that issue was to deduplicate operations in the event queue, and I can imagine that is where the order of execution gets reversed. Does the change log make use of the event queue? If so, this could be the cause of the problem. |
|
This doesn't occur on creating name servers, only zones. Specific this is the call in the class Zone: clean() method which triggers the error in merge: 
|
|
Hmmm ... that's interesting. Boiled down to the minimum it means that I check whether the object has a My first guess would be the latter. |
|
I think @cruse1977 has it nailed down: During import, the zones are created within the branch schema. On merge, the creation of each zone is "replayed" onto the main schema, using the change record from the branch. The zone's primary key is preserved and copied from the branch instance. When the model is then validated prior to calling While perhaps the most obvious solution would be to activate the branch during model validation, this won't work as uniqueness validation will fail for the PK and any other unique fields. Unfortunately I'm not sure there's much we can do to accommodate this particular approach. But I can recommend a workaround if you're open to it: Rather than querying for the object's original attributes under |
|
@jeremystretch Thanks, that looks promising ... I'm using the pattern in several places, so this could sum up to a slightly improved performance as well. Let me see if I can get rid of all the database queries that way. |
|
Update: I no longer do that kind of query now. Fortunately I had already implemenred a mixin that enhances classes by a Unfortunately I run into a different issue now. I still can't merge the branch, just the place where it happens has changed: 
I remember I've seen that one before. I think I have another major issue to tackle. From Jeremy's remarks to #89 I take that when I call |
I believe this was resolved under #94 and will be fixed in the upcoming v0.5.0 release. |
Plugin Version
0.3.1
NetBox Version
4.1-beta1
Python Version
3.11.5
Steps to Reproduce
Expected Behavior
The branch is merged and the zones and the nameserver are now available in the main branch
Observed Behavior
This is not the only way I could reproduce this - at one point I got the same error just with an IP Address, without any NetBox DNS objects involved (unfortunately I didn't get a screen shot, though).
Not sure how this relates to #43 - so far I haven't been able to reproduce that one with a fresh DB.
The text was updated successfully, but these errors were encountered: