aws
Interrupt service deployment + allow for config modification for a failed service
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do * not help prioritize the request If you are interested in working on this issue or have submitted a pull request, please leave a comment
Tell us about your request We heard from customers that they would like to recover from errors faster. There are two use cases here:
- For an already deployed and running service: Customers would like to interrupt a service to recover from a bad config instead of waiting for the default rollback period. This would help improve productivity and help recover from any failures faster.
- For a new service: Customers should be able to modify the config of a service in the create failed state to recover back to a healthy and running state. This would help not having to duplicate the config for a new service creation and instead just fix the specific problem in the failed service.
Describe alternatives you've considered Wait for the service rollback to complete in use case 1. Use the create failed service as read only to debug but customers need to recreate a new service
This is ESSENTIAL. I cannot emphasize how grossly inconvenient it is to have to enter DOZENS OF ENVIRONMENT VARIABLES OVER AND OVER AGAIN because of some random error that causes new deploys to fail leaving starting from SCRATCH as the only option.
I know its this does not directly solve your use case but you can now edit environment variables in the console for a service that is created and running. To directly address your issue, we will work on allowing updates to a failed service and post on this thread as we have more to share.
By console you mean via AWS CLI or is there a way to get shell access to a running container?
In my case I accidentally (twice) create a service and forgot to set the IAM Policy which allows access to my ECR Repository. I was stuck with a service in creation mode for at least 20 minutes. I figured it out at the end but canceling the first one would have been nice.
How has this fundamental feature remained unaddressed after more than a year?
It's insane that we have to completely remove an APP because a Create failed. I was deploying a JSON server just to test app runner and after a failed deployment I will have to delete and recreate the app from scratch.
It completely baffles my mind that this is still hasn't been addressed. Do you really expect us to destroy and recreate the resource if it fails?
Thank you for your patience. We are looking at this feedback and we will keep you updated as we plan and make progress on this issue.
I will implement this for AWS free of charge because it would probably take less time than working around it as the end-user
Any updates on this? Still trying to wrap my head around how this was left out. Thank you for any help on the issue. If you can shed some light and rough ETA on this.
@amitgupta85 what is the ETA on this? This is an enormous omission from an otherwise fantastic service. This will help everyone immensely.
Hello all, Thank you for the feedback. App runner is actively working on this feature and we will post our updates soon.
App Runner now support update and rebuild of a service in failed state. See launch announcement for more details: https://aws.amazon.com/about-aws/whats-new/2023/06/aws-app-runner-update-rebuild-failed-service/
@snnles Is there any ongoing work on interrupting an in-progress deployment? (like EB's abort-environment-update)
