Return 409 on DELETE /users/{name} if server has a pending stop

I’m writing some stress/load test scripts which scales up a bunch of users/servers (pods) and then scales them back down to test the hub and I was hoping to just delete users without needing to stop the servers and poll those first, but I noticed that user delete can fail with a 400 if the server is pending a stop [1][2]. I was wondering if there any thoughts on changing those 400 responses to 409s instead so client side tooling can retry on 409 rather than have to parse that 400. I realize this would be an API change so maybe not worth the churn.

The alternative is calling [3] and if I get a 204 back go ahead and delete the user, else if I get a 202 back poll until the server is gone and then delete the user. I’m polling either way but think a 409 would be more appropriate than a 400 on the user delete request if the server is stopping.