Package: reflex-hosting-cli and/or the hosting API (reproduced with both main at ea035ea47 and #7207 at 988718e78)
After a rollback, reflex cloud apps status <deployment> --watch exits with Success: deployment completed successfully. For a short time after that, the server still treats the previous deployment as the app's current one. A rollback issued right away is refused:
$ reflex cloud apps rollback D1 --app-id A # D2 is current
Success: Rollback to deployment D1 started.
$ reflex cloud apps status D1 --watch
Success: deployment completed successfully
$ reflex cloud apps rollback D2 --app-id A # immediately after
this deployment is already the app's current deployment
[exit=1]
About 20 seconds later the same rollback D2 succeeds, and apps history / apps inspect show D1 as Running / latest_deployment. main's CLI hits the same thing in the opposite direction.
Expected: --watch returns only once the deployment is the app's current deployment, so a script can chain commands after it. If that isn't possible, the server's "current deployment" check should agree with the status --watch reads.
Package:
reflex-hosting-cliand/or the hosting API (reproduced with bothmainatea035ea47and #7207 at988718e78)After a rollback,
reflex cloud apps status <deployment> --watchexits withSuccess: deployment completed successfully. For a short time after that, the server still treats the previous deployment as the app's current one. A rollback issued right away is refused:About 20 seconds later the same
rollback D2succeeds, andapps history/apps inspectshow D1 asRunning/latest_deployment.main's CLI hits the same thing in the opposite direction.Expected:
--watchreturns only once the deployment is the app's current deployment, so a script can chain commands after it. If that isn't possible, the server's "current deployment" check should agree with the status--watchreads.