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.
[1] https://github.com/jupyterhub/jupyterhub/blob/3663d7c8fcba2118dd469a8a4cca540cc63a39cf/jupyterhub/apihandlers/users.py#L173
[2] https://github.com/jupyterhub/jupyterhub/blob/3663d7c8fcba2118dd469a8a4cca540cc63a39cf/jupyterhub/apihandlers/users.py#L179
[3] https://jupyterhub.readthedocs.io/en/stable/_static/rest-api/index.html#operation--users--name--server-delete