-
released this
2026-05-08 15:19:18 -04:00 | 9 commits to main since this releaseBug Fixes
- Critical: stock control returned qty=0 fleet-wide for packages with a
primaryStorageProfile.StockControl::capForStorage()was comparing the package'sprimaryStorageProfileagainstotherStorage[].id, but the VirtFusion API exposes that field as a storage type code (mirrorsserver_packages.storage_type) — a filter that should matchotherStorage[].storageType. Pool ids are unique per hypervisor (e.g. 23/28/30 for the same logical mountpoint on three nodes) and almost never collide with the type-code domain (0=local, 4=mountpoint, etc.), so the check returned 0 for every hypervisor and silently zeroed inventory for any product that opted into stock control with a non-default storage profile. Symptoms: every stock-controlled VPS product showed qty=0 in WHMCS despite abundant memory/CPU/IPv4 capacity; only workarounds were disabling stock control or removingprimaryStorageProfilefrom the package, both of which defeat the gating. Fix: matchpool.storageTypeinstead ofpool.id; walk all pools that match (a hypervisor may carry multiple pools of the same type) and pick the one that fits the most VMs; treat a disabled pool as skip-and-continue rather than a hard zero, so an enabled peer of the same type still contributes. Also renamed the internal$profileIdparameter to$storageTypeIdso future readers don't fall into the same naming trap. Verified on a 3-hypervisor cluster: qty went from 0/0/0/0/0/0/0/0 to 66/32/15/7/3/1/32/15 across the VPS-1 through VPS-32 products with no other config change.
Full Changelog: v1.4.0...v1.4.1
Downloads
- Critical: stock control returned qty=0 fleet-wide for packages with a