i payed for above offer,
but find < 512 MBram10 GBdisk 512 GBtraffic> in cp
test only?
id=718905
~~~
Offer #98
SKU: RYZEN SKU# V00-D3
1 cores
384MB RAM
15GB NVMe Storage
1 IPv4
1792GB Bandwidth
LOS ANGELES, CA
$7.60 per YEAR
All orders that bugged out should be logged. I'll be going through and catching up on fixing them now. After I'm done I'll make another post with more information and then we can go through any problems still left over with the provisioning. Give me about an hour or so and I'll provide another update.
There's one order stuck on provisioning which I'm investigating further now, and two orders stuck on vserverid not found.
I'm going to be attempting to rework the provisioning system from scratch again, if that doesn't work I'll revert back to the old version. By old version I mean about a week or two older. That version was tested thoroughly for the 512MB/10GB bug, but has some bugs of its own that would slow down the provisioning process (it doesn't use the new logic of clustering provisioning.) I'll let you guys know what version we end up on after I'm done. But for now we're still on the current version that has a high chance of provisioning as 512MB/10GB which will be automatically logged and corrected (no need to report that problem here) and a small chance of having the vserverid bug as well. I'll try to reintroduce the vserverid bug catcher (since it wasn't happening frequently, it was removed, but we used to have logic that reverted the entire process if it caught a vserverid bug and retried. I disabled it since if it gets stuck and retried over and over and over it could potentially cause other problems.)
@tototo said:
Offer 96 is listed as $7.60 but it seems to be actually lower than that?
This is another bug. It's not a major bug, it's a bug with price reduction handling. It makes sure it gets the important part done correctly which is actually updating the price on the service that you order, but pays less attention to updating the displayed price. This isn't a big deal as long as prices are dropping, but if prices are going up it can be problematic. Basically, there's sometimes a delay on it updating what is displayed. Since that's not prioritized in the process. It usually fixes itself in a couple minutes. Let me know in this case if it doesn't catch itself soon and correct it. Actually I'm not sure what you're talking about specifically unless I'm looking at something wrong, but we're currently at offers 100 through 102, right? That might be another bug where your page needs to be reloaded. Let me know if that's the case as I'll have to look into that.
There used to be a bug that caused it to do that (stop updating) but I reworked the frontend to make that not a possibility so I'm wondering if it's from your backend notifications or how long you've had the page open.
Right now I'm seeing offer 100 listed as $8.28 but being actually $7.04.
I've also caught another bug, where the system completely errors out on the ordering page, related to the price change warning (most likely.) Yay, bugs! It goes away after a refresh.
@msatt said: @VirMach - Same bug, unfortunately Amsterdam Offer 82 not applied correctly to Invoice 1661531
Thanks,
Are the Amsterdam ones the only ones that are broken? I guess I need to wait and not try for another ams offer...
No, Amsterdam offers are just more popular, so more orders, so more reports. Amsterdam is filled differently than other locations so it's popping out offers people like more I think. They also have different multipliers per location so perhaps Amsterdam is giving out those type of offers (that match preferences.) Or maybe people just like that location.
We just got a big batch of new orders, going through those as well now to fix the above bugs for them. These orders were placed after my message above.
Provisioning bug is related to another WHMCS bug, where while paying the invoice/checking out, customer creates a second user account. We've never been able to figure this bug out, as usually we don't receive any feedback from customers that experience it. So if you're order #611199, or invoice #1661547, please reach out here so we can work out what could have caused that bug to occur.
This is for "MassivePrivate-VM"
I thought the name was funny so I added that in as well for clarification.
@VirMach Yeah everything you said is correct. I was late to post because I was doing some checks, but it’s certain that it wasn’t Offer #100-102. In other words, it wasn’t a bug where the offer page failed to update.
I rushed to place an order to check if the actual price being lower than the offer page price was a bug, but I should’ve waited for Offer #100 instead of jumping on #98 lol
Yes, just confirming there will be a good amount of those, after I add them into the pool. They'll be on the chunkier side, I think, because we're almost out of IP addresses in Miami.
@animeiscool said:
Update: Seems like offer #54 is going through the same thing. $11.52 on flash sale site, but cheaper price on the main website.
Update 2: Offer #53 is now $53.01 on the main site, compared to the $10.01 on the flash sale site.
Idk what exactly is happening, but I believe in VirMach.
This was a massive bug related to the system halting per the post above yours. I think it worked itself out. It was just displaying the older offer mixed with a newer offer. This shouldn't happen ever again, unless it happens again due to the reason the bug occurred which was me editing the code in a really bad way.
Speaking of which, I had to revert the code to fix it. The bug I was trying to fix which was not reported is that sometimes when plan gets sold out, it just gets stuck.
@mucstudio said:
It shows that it has been opened normally, but when I click in, I can't find the server!!!
You're one of the two vserverid bugs. I'm still working on that, sorry for the wait.
Not happy about this one. But at least it's only for two of them. But that will make it so much harder to catch.
@sh97 said:
Feeling the RAM is kinda imbalanced for the offers
I noticed this issue as well, I don't have a proper fix it for it other than making it reduce the other resources, which could be a fix since it would also reduce price. I was actually working on a better fix where in those situations it gives you the extra disk and whatever else but just charges less for it, and uses RAM as the primary price indicator.
I'll see what we can do about it though but the "problem" is basically that it's too accurate now. It just means we have Ryzen nodes that are limited on memory as opposed to Epyc or E5. And a lot of the crazy high disk offers in the past (from filling nodes that had a lot of disk before we switched over have expired, and a lot of the crazy low disk offers have been renewed at a higher rate, that's left nodes with kind of with a lot of disk space. And since they're Ryzen, and CPU usage is now low as a result, for offers mostly sold on E5's in the past... yeah.)
Oh really important regarding RAM: the higher RAM plans are currently less likely to show up because they'd be on nodes with a lot of memory left over, which happen to also be nodes that are locked off/have been locked off for some time. We went with the nodes being unlocked that are the most stable which happen to be the nodes with the highest amount of memory used since they're usually actively being refilled and just higher memory usage in general from being online for so long. So once these get entered back into the pool you'll start seeing your higher memory offers.
@tototo said: @VirMach Yeah everything you said is correct. I was late to post because I was doing some checks, but it’s certain that it wasn’t Offer #100-102. In other words, it wasn’t a bug where the offer page failed to update.
I rushed to place an order to check if the actual price being lower than the offer page price was a bug, but I should’ve waited for Offer #100 instead of jumping on #98 lol
Let me know if you notice any specific way this works out, as in let me know if it appears to be after a price drop, it's lower on the order page, and then corrects itself or if it stays broken the entire time. No rush, just whenever it's noticed if you have more information for me on it.
It's already on my (growing) list of things to fix but lower on the priority list for now.
Comments
Virmach is alive! I'll go check my servers after a year and see if they are idling peacefully.
Are the Amsterdam ones the only ones that are broken? I guess I need to wait and not try for another ams offer...
i payed for above offer,
but find < 512 MBram10 GBdisk 512 GBtraffic> in cp
test only?
id=718905
~~~
Offer #98
SKU: RYZEN SKU# V00-D3
1 cores
384MB RAM
15GB NVMe Storage
1 IPv4
1792GB Bandwidth
LOS ANGELES, CA
$7.60 per YEAR
All orders that bugged out should be logged. I'll be going through and catching up on fixing them now. After I'm done I'll make another post with more information and then we can go through any problems still left over with the provisioning. Give me about an hour or so and I'll provide another update.
Offer 96 is listed as $7.60 but it seems to be actually lower than that?
512MB/10GB disk issues have ben fixed.
There's one order stuck on provisioning which I'm investigating further now, and two orders stuck on vserverid not found.
I'm going to be attempting to rework the provisioning system from scratch again, if that doesn't work I'll revert back to the old version. By old version I mean about a week or two older. That version was tested thoroughly for the 512MB/10GB bug, but has some bugs of its own that would slow down the provisioning process (it doesn't use the new logic of clustering provisioning.) I'll let you guys know what version we end up on after I'm done. But for now we're still on the current version that has a high chance of provisioning as 512MB/10GB which will be automatically logged and corrected (no need to report that problem here) and a small chance of having the vserverid bug as well. I'll try to reintroduce the vserverid bug catcher (since it wasn't happening frequently, it was removed, but we used to have logic that reverted the entire process if it caught a vserverid bug and retried. I disabled it since if it gets stuck and retried over and over and over it could potentially cause other problems.)
This is another bug. It's not a major bug, it's a bug with price reduction handling. It makes sure it gets the important part done correctly which is actually updating the price on the service that you order, but pays less attention to updating the displayed price. This isn't a big deal as long as prices are dropping, but if prices are going up it can be problematic. Basically, there's sometimes a delay on it updating what is displayed. Since that's not prioritized in the process. It usually fixes itself in a couple minutes. Let me know in this case if it doesn't catch itself soon and correct it. Actually I'm not sure what you're talking about specifically unless I'm looking at something wrong, but we're currently at offers 100 through 102, right? That might be another bug where your page needs to be reloaded. Let me know if that's the case as I'll have to look into that.
There used to be a bug that caused it to do that (stop updating) but I reworked the frontend to make that not a possibility so I'm wondering if it's from your backend notifications or how long you've had the page open.
Right now I'm seeing offer 100 listed as $8.28 but being actually $7.04.
I've also caught another bug, where the system completely errors out on the ordering page, related to the price change warning (most likely.) Yay, bugs! It goes away after a refresh.
No, Amsterdam offers are just more popular, so more orders, so more reports. Amsterdam is filled differently than other locations so it's popping out offers people like more I think. They also have different multipliers per location so perhaps Amsterdam is giving out those type of offers (that match preferences.) Or maybe people just like that location.
We just got a big batch of new orders, going through those as well now to fix the above bugs for them. These orders were placed after my message above.
Provisioning bug is related to another WHMCS bug, where while paying the invoice/checking out, customer creates a second user account. We've never been able to figure this bug out, as usually we don't receive any feedback from customers that experience it. So if you're order #611199, or invoice #1661547, please reach out here so we can work out what could have caused that bug to occur.
This is for "MassivePrivate-VM"
I thought the name was funny so I added that in as well for clarification.
@VirMach Yeah everything you said is correct. I was late to post because I was doing some checks, but it’s certain that it wasn’t Offer #100-102. In other words, it wasn’t a bug where the offer page failed to update.
I rushed to place an order to check if the actual price being lower than the offer page price was a bug, but I should’ve waited for Offer #100 instead of jumping on #98 lol
Yes, just confirming there will be a good amount of those, after I add them into the pool. They'll be on the chunkier side, I think, because we're almost out of IP addresses in Miami.
This was a massive bug related to the system halting per the post above yours. I think it worked itself out. It was just displaying the older offer mixed with a newer offer. This shouldn't happen ever again, unless it happens again due to the reason the bug occurred which was me editing the code in a really bad way.
Speaking of which, I had to revert the code to fix it. The bug I was trying to fix which was not reported is that sometimes when plan gets sold out, it just gets stuck.
You're one of the two vserverid bugs. I'm still working on that, sorry for the wait.
Not happy about this one. But at least it's only for two of them. But that will make it so much harder to catch.
I noticed this issue as well, I don't have a proper fix it for it other than making it reduce the other resources, which could be a fix since it would also reduce price. I was actually working on a better fix where in those situations it gives you the extra disk and whatever else but just charges less for it, and uses RAM as the primary price indicator.
I'll see what we can do about it though but the "problem" is basically that it's too accurate now. It just means we have Ryzen nodes that are limited on memory as opposed to Epyc or E5. And a lot of the crazy high disk offers in the past (from filling nodes that had a lot of disk before we switched over have expired, and a lot of the crazy low disk offers have been renewed at a higher rate, that's left nodes with kind of with a lot of disk space. And since they're Ryzen, and CPU usage is now low as a result, for offers mostly sold on E5's in the past... yeah.)
Oh really important regarding RAM: the higher RAM plans are currently less likely to show up because they'd be on nodes with a lot of memory left over, which happen to also be nodes that are locked off/have been locked off for some time. We went with the nodes being unlocked that are the most stable which happen to be the nodes with the highest amount of memory used since they're usually actively being refilled and just higher memory usage in general from being online for so long. So once these get entered back into the pool you'll start seeing your higher memory offers.
Let me know if you notice any specific way this works out, as in let me know if it appears to be after a price drop, it's lower on the order page, and then corrects itself or if it stays broken the entire time. No rush, just whenever it's noticed if you have more information for me on it.
It's already on my (growing) list of things to fix but lower on the priority list for now.