v1.9.0 regression: "Problems resolving relation 'module'" logged for every interface/power-port with an assigned NetBox module (VMware-only source, check_redfish not configured)

[peterbaumert]

v1.9.0 regression: "Problems resolving relation 'module'" logged for every interface/power-port with an assigned NetBox module (VMware-only source, check_redfish not configured)

Summary

After upgrading from v1.8.1 to v1.9.0, every run logs hundreds of ERROR: Problems resolving relation 'module' for object '...' and value '...' lines during the initial "Querying necessary objects from NetBox" phase — before any source-specific (vCenter) processing even begins. This happens even though our config only uses the vmware source; check_redfish is not configured at all.

Confirmed via direct A/B test (same NetBox instance, same settings.yaml/secrets.yaml, only the image tag changed):

	v1.8.1	v1.9.0
ERROR count	0	290
Dry-run (-n) completion	n/a	Completes cleanly, no crash

Root cause (traced in the image)

/app/module/netbox/object_classes.py — both NBInterface and NBPowerPort got a new, unconditional data model field in this release:

class NBInterface(NetBoxObject):
    def __init__(self, *args, **kwargs):
        self.data_model = {
            ...
            # NetBox cascade-deletes module components, so the module owns its interfaces
            "module": NBModule
        }

This applies to every interface/power-port object loaded into inventory, regardless of which source(s) are configured. The generic relation-resolution code (resolve_relations(), around line 850-904) then tries to look up the matching NBModule object:

resolved_data = self.inventory.get_by_data(data_type, data=data_to_find)
...
if resolved_data is not None:
    self.data[key] = resolved_data
else:
    log.error(f"Problems resolving relation '{key}' for object '{self.get_display_name()}' and value '{data_value}'")

This fails for every interface that has an existing module assignment in NetBox, because the general "query necessary objects from NetBox" pre-fetch step doesn't load dcim/modules into the in-memory inventory cache unless the check_redfish source (and presumably model_components_as_modules) is also configured and active. We only use the vmware source, so that cache is empty, and the lookup fails unconditionally.

Importantly, this isn't limited to devices irrelevant to our sync (e.g. Cisco switches) — it also fires for real ESXi host NICs with existing Embedded LOM/Embedded ALOM modules, i.e. devices actually touched by the vmware source's host-tracking.

Steps to reproduce

1. Have any devices in NetBox with interfaces that have a module field populated (NetBox-native DCIM modules, not necessarily created by netbox-sync itself).
2. Run ghcr.io/bb-ricardo/netbox-sync:1.9.0 with only a vmware source configured (no check_redfish), -n dry-run flag is fine to reproduce.
3. Observe dozens/hundreds of ERROR: Problems resolving relation 'module' for object '<interface-name> (<device>)' ... lines during the initial NetBox object query phase, before vCenter data collection even starts.
4. Re-run the identical config against v1.8.1 — these errors do not occur at all.

Checked for related settings

model_components_as_modules exists in settings-example.ini but is explicitly documented as check_redfish-only (requires NetBox >= 4.3) and defaults to False (already off in our config). It has no effect on this — the error occurs in generic relation-resolution code shared by all sources, not gated by this flag.

Impact

• Run does not crash and dry-run completes, so this may be "just" log noise today — but it's unclear whether it also silently affects real (non-dry-run) writes to these interfaces/power-ports (e.g. whether the unresolved module field gets written back as null, stripping an existing module assignment, or whether orphan-cleanup logic treats these objects incorrectly).
• Given the sheer volume (290 errors on our ~70-host environment) this will spam logs/alerting on any install that has NetBox-native module assignments and doesn't use check_redfish.

Environment

• netbox-sync: 1.9.0 (ghcr.io/bb-ricardo/netbox-sync:1.9.0), regression vs 1.8.1
• Source: vmware only
• NetBox: recent 4.x (exact version omitted — redact as needed)

[marcinpsk]

Hi @peterbaumert
thanks! Looks like logging noise only.

[semx]

Thanks for the detailed report and the A/B run. It is log noise only: the unresolved value was never written back, so the module of those interfaces and power ports stays as NetBox has it. #576 from @marcinpsk only logs the error for object types the run actually reads from NetBox; it's merged and will be released as 1.9.1.