You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When the Proxmox module is set up and it fails setting up an order for some reason, deleting that order results in an unrelated VM being randomly deleted.
A possible reason I could think of is the Proxmox module trying to start VMs with IDs beginning with 101 and increasing. When that order fails for some reason and you try to delete the order, it deletes what it thinks to be the VM from that order. So it attempts to delete VM 101.
However, VM 101 is a previously created, completely unrelated VM. Now it completely removed VM 101 instead of whatever it tried to create and failed.
To Reproduce
Steps to reproduce the behavior:
Have existing VMs in your Proxmox server
Create an order and try getting it to fail (I don't know how)
Try deleting that order
Now see if it deletes an existing, unrelated VM
Expected behavior
It absolutely should not delete an unrelated VM. We need to make sure that VM is created using FOSSBilling and tied to that specific order. VM IDs should also not interfere with existing VMs.
The text was updated successfully, but these errors were encountered:
This is part of a larger issue with VM IDs. This has been rewritten completely, and it's not possible to happen anymore, as VM-IDs now consist of the users id, the order id and a random four-digit number.
Describe the bug
When the Proxmox module is set up and it fails setting up an order for some reason, deleting that order results in an unrelated VM being randomly deleted.
A possible reason I could think of is the Proxmox module trying to start VMs with IDs beginning with 101 and increasing. When that order fails for some reason and you try to delete the order, it deletes what it thinks to be the VM from that order. So it attempts to delete VM 101.
However, VM 101 is a previously created, completely unrelated VM. Now it completely removed VM 101 instead of whatever it tried to create and failed.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
It absolutely should not delete an unrelated VM. We need to make sure that VM is created using FOSSBilling and tied to that specific order. VM IDs should also not interfere with existing VMs.
The text was updated successfully, but these errors were encountered: