Volume stuck in pending_destroy for 11 hours

I can’t delete a volume that is stuck in pending destroy. It is also preventing me from scaling up new regions. They try to claim the volume and fail.

same issue here

When you destroy a volume, it’s actually soft-deleted first; that gives us a little time to recover the data if the volume was destroyed by mistake. Volumes waiting to be fully destroyed are in the pending_destroy state that you saw.

What changed is that flyctl switched to using the Machines API to work with volumes, and the new Machines API endpoints include pending_destroy volumes. Because of a bug, flyctl didn’t filter these out and tried to use them like any other volume during deployments. Sorry that you ran into this! The bug was fixed in v0.1.78, released on Monday (August 14).

(v0.1.78 also restores the old behavior of fly volumes list: you won’t see pending_destroy volumes there anymore. You can still find them by using the Machines API directly.)

Thanks for letting me know. I’ve been working through a workflow that will allow me to script the process of recreating my entire app and restoring all data, because I can’t really rely on support to respond in time when bugs like this occur. It took several days for this to be fixed. It would help if you guys created regression tests for the cli to avoid this in the future.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.