percent calculation of server change-type is a way off - stuck at 80%

[c33s]

TL;DR

i started the type change from ccx31 240 GB max disk 22 GB used to ccx53 600 GB max disk, at 20:45.

after about 10-15min i was at 80% since then i am stuck at 80% currently at 2h07min. the gui shows the same 80%. thats not very accurate.

Expected behavior

if something like disk pre-allocation and/or copying between datacenters have to take place this should be calculated into the percentage and also outputted on the cli.

it is relevant if i assume that the virtual machine i just shutdown, a dynamic disk size is adapted and the vmachine starts again ~1-2min downtime and in reality 22gb get copied from one datacenter to another and then a low prio full disc allocation of 600 gb takes place (or in worst case the 600gb image gets copied to another datacenter after the new size allocation).

also information about how long this could take should be in the docs and maybe even in the cli output if i start the process. at least some info that the process is correctly running and maybe an eta on how long it takes to better prepare server downtimes.

some info if i can simply close the terminal where i opened hcloud to let it continue on backend side without my pc running would be helpful.

Observed behavior

inaccurate time calculation and not knowing if everything is ok or how long it will take.

Minimal working example

hcloud server change-type --keep-disk=false app31.example.com ccx53

Log output

Additional information

No response

[c33s]

Waiting for change_server_type   80% 2h33m34s (server: <redacted>)
hcloud: Limit of '7200' requests per hour for token '<redacted>...' reached. (rate_limit_exceeded)

not really a desired output

i did 3 further change type: as the other servers changed type in a few minutes (may it was even only one) and the one server is still stuck in "starting" mode i think it is a backend bug but even then i better handling without running into a rate limit would be good on cli side

[phm07]

This is indeed a backend bug and there is nothing we can do in the CLI to fix that. You can open a support ticket in the Console so it gets forwarded to the responsible team. As for the request limit, you can change the poll interval in the CLI configuration (see hcloud config) so the limit isn't reached as quickly. The default poll interval is 500ms which would meet the 7200 req/hr limit exactly.

[c33s]

support ticket already filed and "answered": this can happen and as user i have no way to stop/cancel/retry it.

but shouldn't the cli tool somehow handle this? at least detect that the time is unusal long and stop polling and/or tell the user they can exit the program.

the other thing i proposed: allow to only trigger it and exit. i think there quite some ways to handle this in the cli or do i miss something?