Skip to content

fix(ingester): don't clear a cluster's scope oneof when building a VirtualMachine - #107

Closed
ldrozdz93 wants to merge 1 commit into
developfrom
fix/cluster-scope-oneof-guard
Closed

fix(ingester): don't clear a cluster's scope oneof when building a VirtualMachine#107
ldrozdz93 wants to merge 1 commit into
developfrom
fix/cluster-scope-oneof-guard

Conversation

@ldrozdz93

Copy link
Copy Markdown
Contributor

Problem

VirtualMachine(cluster=…, site=…) writes scope_site into the caller's Cluster message. Cluster.scope is a protobuf oneof, so that write silently deletes whatever scope the caller had already set — a SiteGroup, Location or Region.

cluster = Cluster(name="c1", scope_site_group=SiteGroup(name="sg-1"))
VirtualMachine(name="vm-1", cluster=cluster, site=Site(name="site-1"))

cluster.WhichOneof("scope")   # "scope_site" — the SiteGroup is gone

The guard was not cluster.HasField("scope_site"), which is False while a sibling of the oneof holds the scope. So "unset" reads as true even though the cluster is already scoped, and CopyFrom clears it.

Fix

Guard on WhichOneof("scope") instead. This is a strict tightening of the old check — an unscoped cluster is still filled from the VM's site, an already-scoped one is left alone.

Why it matters downstream

The vCenter integration scopes a Cluster with a SiteGroup when its ESXi hosts span multiple NetBox Sites. Building any VM in that cluster replaced the SiteGroup with that VM's own Site, so the emitted payload carried two contradictory copies of the same Cluster: the root entity with the mutated scope_site, and the nested device.cluster ref with the correct scope_site_group. The root entity is the one that creates/updates the Cluster in NetBox, so the wrong value won — and which Site won depended on which VM happened to be built first.

Measured on nbl-vmware-vcenter, multi-site fixture, no integration code changed:

root cluster nested device.cluster
released SDK scope_site: DefaultSite scope_site_group: SiteGroup-MixedTagCluster
this branch scope_site_group: SiteGroup-MixedTagCluster scope_site_group: SiteGroup-MixedTagCluster

Verification

  • pytest tests/ — 214 passed, including a new regression test; ruff check netboxlabs/ tests/ clean.
  • Pre-existing test_virtual_machine_instantiation_with_cluster_without_site still passes, so the fill-when-unscoped shortcut is unchanged.
  • End-to-end against a live vCenter via worker-cli --dry-run, released SDK vs this branch: 144 entities, identical output. Single-site clusters still receive scope_site.
  • nbl-vmware-vcenter suite on this branch: 124 passed, 2 failed. Both failures are golden files that currently record the mutated scope (duplicate IPs across sites create per-site VRFs, mixed site tags produce DefaultSite for untagged hosts); they will be regenerated on the integrations side.

Not in this PR

  • ingester.py is generated, so the same guard needs to go into the generator or the next regeneration will revert it. Suggested general form: if a shortcut's target field belongs to a multi-member oneof, guard on WhichOneof(<oneof>), otherwise HasField(<field>). Today that rewrites exactly 1 of the 20 shortcut writes, and it pre-empts the same bug for IPAddress.assigned_object, MACAddress.assigned_object, WirelessLAN.scope, VLANGroup.scope, Prefix.scope, Service.parent_object, InventoryItem.component and CustomFieldValue.value.
  • Separate finding in the same shortcut table: IPAddress(assigned_object_vm_interface=…, device=…) raises ValueError: Protocol message VMInterface has no "device" fieldVMInterface links via virtual_machine, so that shortcut targets a field that does not exist on the message.

…rtualMachine

VirtualMachine(cluster=..., site=...) filled the cluster's scope_site
whenever HasField("scope_site") was False. Cluster.scope is a oneof, so
that guard is also False when the caller already scoped the cluster to a
SiteGroup, Location or Region — and CopyFrom then silently cleared it.

Guard on WhichOneof("scope") instead: the shortcut still fills an
unscoped cluster, but leaves an already-scoped one alone.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@ldrozdz93
ldrozdz93 requested a review from Copilot July 30, 2026 06:39
@github-actions

github-actions Bot commented Jul 30, 2026

Copy link
Copy Markdown

Coverage

Coverage Report
FileStmtsMissCoverMissing
/opt/hostedtoolcache/Python/3.11.15/x64/lib/python3.11/site-packages/netboxlabs/diode/sdk
   chunking.py33197%112
   client.py5674293%202–203, 222–224, 227–230, 522, 590, 595, 599, 682–687, 732–734, 764, 768, 772, 794, 815, 817, 891, 922, 930, 992–993, 1002, 1035, 1062, 1067–1068, 1097, 1102–1105
   exceptions.py44393%69, 82–83
TOTAL6594693% 

Tests Skipped Failures Errors Time
214 0 💤 0 ❌ 0 🔥 2.107s ⏱️

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Ready to approve

The change corrects oneof-presence detection without altering the intended “fill when unscoped” behavior, and includes a focused regression test for the previously failing case.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR fixes a protobuf oneof mutation bug in the ingester’s VirtualMachine(...) shortcut logic where setting cluster.scope_site could inadvertently clear an already-populated sibling scope field (e.g., scope_site_group) on the caller-provided Cluster message.

Changes:

  • Tighten the guard for populating cluster.scope_site from site by using cluster.WhichOneof("scope") instead of cluster.HasField("scope_site").
  • Add a regression test ensuring an existing Cluster.scope_site_group is preserved when building a VirtualMachine with a site.
File summaries
File Description
netboxlabs/diode/sdk/ingester.py Prevents clearing sibling scope_* fields in the Cluster.scope oneof when applying the VM’s site shortcut.
tests/test_ingester.py Adds a regression test covering the “cluster already scoped to SiteGroup” case.
Review details
  • Files reviewed: 2/2 changed files
  • Comments generated: 0
  • Review effort level: Low

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

@ldrozdz93 ldrozdz93 closed this Jul 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants