Closed the-vampiire closed 1 year ago
Indeed. The only way seems to be to delete it and create a new one from scratch. This is quite frustrating e.g. when you have quite some environment variables to add
Just hit this today. My initial container image had a problem and the service failed to create. The only solution was to delete the service and recreate it. This seems like a pretty serious limitation with AppRunner.
This is a bit of a show stopper as deleting the instance means the loss of the App URL. Recreating the service generates a new url which even if you use a custom domain requires the DNS to propagate.
@tcldr I’m with you. i havent used apprunner since opening this issue a few months ago.
This looks like a dupe of #49 and is listed as 'Coming soon' – but that was back in September. I'll stick to Fargate/ECS for now, but am missing the cost efficiency of App Runner's pay per request load balancing.
Happy to announce that this feature is now live in all regions. See https://aws.amazon.com/about-aws/whats-new/2023/06/aws-app-runner-update-rebuild-failed-service/.
Community Note
Tell us about your request when a service deployment fails due to misconfiguration allow the configuration to be modified in service states besides "running" or "paused" (such as
CREATE_FAILED
)in my case an error in an environment variable caused the app to crash during startup. there is no way to remedy this as trying to save changes to configuration environment variables is locked with error (this is from console but same from CLI):
this is a catch-22 as the service page Actions only allows delete to be selected (pause and resume are grayed out).
Describe alternatives you've considered
the only alternative appears to be to delete the entire service and start from scratch
Additional context it would be nice to cancel the deployment when application logs show errors. if the app exits due to error that should be detected before waiting for health checks. instead it ran an additional 15 mins of trying to health check before finally failing.
this may be expected behavior normally (as it tries to revert to previous deployment) but on a first deployment (where config issues are most prevalent) there is nothing to fall back to so it is just burning time