mirror of
https://github.com/GoodOlClint/PSProxmoxVE.git
synced 2026-09-03 18:55:33 +00:00
goodolclint-claude[bot]
2dff02f2bd
PveNetwork already deserialised bridge_vlan_aware as BridgeVlanAware, so a VLAN-aware bridge could be read back but never created or changed. Both write paths now take a -BridgeVlanAware switch. Clearing the flag does not use bridge_vlan_aware=0. PVE merges the supplied keys onto the stored stanza and accepts that 0 without acting on it, so the obvious form is a silent no-op: an integration run against PVE 9 issued it and Get-PveNetwork still reported 1. The endpoint's delete list is what actually removes the key. The API schema advertises a plain boolean and gives no hint of this, which is why the behaviour is pinned by an integration test rather than inferred. Set-PveNetwork guards the switch on BoundParameters so an update that omits it leaves the flag alone; the create path follows the existing -Autostart form. Only bridge_vlan_aware is added. bridge_vids is an independent parameter that PVE defaults to 2-4094, and the issue asks only for the flag. Coverage: the integration suite pins create, disable, re-enable, and that an unrelated Set leaves the flag alone -- that last one kills a mutant that drops the BoundParameters guard, which every other test survives. A model test pins the read path the assertions depend on. The Pester unit tests assert only parameter metadata; the defect is server-side, so nothing offline can catch it. Closes #92