Is 'chalice deploy' transactional?

This can be a bit of a topic of discussion. But here is some context.

Over the last year, I have experimented with a few deployment models supported by Chalice. While I acknowledge that for advanced use cases, CDK or Terraform or SAM is needed, the simple 'chalice deploy' has value even beyond just dev workflows.

One reason is that for 90% of the small to medium sized business, static environments (through separated static VPCs and/or separated accounts) like dev -> test -> prod is good enough. Over time they can improve their level of sophistication but I believe they would still want to eventually stick with 'chalice deploy'.

My simple scheme through GitHub workflows works perfectly for this. With one exception and that also results in a question.

Was 'chalice deploy' meant to set the state of the app inside AWS to how it is defined in the code? Was it a deliberate design decision to only do upsert type things when changing the state of the app inside AWS?

For example, I have noticed that if I rename a pure Lambda handler, the old one still stays in place. And if it is driven by an event schedule, that's not that great because I have to remove it by hand with some deadline (in minutes or hours).

In the future, are there plans to add that option, i.e. a flag in the config which will clean up things during a deploy?

Start by examining how `chalice deploy` currently reconciles AWS resources, especially renamed Lambda handlers and event schedules. Determine whether the desired behavior is a cleanup flag or a documented transactional guarantee, then define the affected resource types and tests needed to show that removed resources are handled safely.

Written by the indexing model from the issue text.