consider treating No such container as a successful delete

[dixler]

Hello!

• Vote on this issue by adding a 👍 reaction
• If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Updating (we)

View in Browser (Ctrl+O): https://app.pulumi.com/kyle-pulumi-corp/pulumi-yaml-image-update-issue/we/updates/41

     Type                       Name                               Status                   Info
     pulumi:pulumi:Stack        pulumi-yaml-image-update-issue-we  **failed**               1 error
 ~   ├─ docker:index:Image      image                              updated (0.89s)          [diff: ~build]
 +-  └─ docker:index:Container  container                          **replacing failed**     1 error


Diagnostics:
  pulumi:pulumi:Stack (pulumi-yaml-image-update-issue-we):
    error: update failed

  docker:index:Container (container):
    error: deleting urn:pulumi:we::pulumi-yaml-image-update-issue::docker:index/container:Container::container: 1 error occurred:
    	* Error stopping container 30318d89ad7e63c74766280167c643c45d19e868dc98ee3f16d2b5025b2bca14: Error response from daemon: No such container: 30318d89ad7e63c74766280167c643c45d19e868dc98ee3f16d2b5025b2bca14

Resources:
    ~ 1 updated
    1 unchanged

Duration: 3s

When the old container is no-longer running, trying to stop the old container leads to an error. I would expect it to treat the missing container as a successful delete, but others may disagree (hence marking this an enhancement).

Affected area/feature

[danielrbradley]

This sounds like it could potentially be a good usability improvement - still emitting a warning though.

Could there be any kind of edge-case where you've actually connected to the wrong daemon and therefore it would not be there? Or is there only ever the single local instance we'd be considering?

Currently, would this be fixed by running a refresh which would detect that it's now missing? Doing a refresh feels like it could be the more correct route to go because essentially what you're seeing is drift between code and reality due to having manually modified your infrastructure (stopped the container) ... or maybe it stopped itself.

If we want to stick with the refresh approach, perhaps we could include some guidence when displaying this error to the user to use refresh to fix this. E.g.:

Container not found, use `pulumi refresh` to update the stack state: Error stopping container 30318d89ad7e63c74766280167c643c45d19e868dc98ee3f16d2b5025b2bca14: Error response from daemon: No such container: 30318d89ad7e63c74766280167c643c45d19e868dc98ee3f16d2b5025b2bca14. 

[mattfysh]

thanks for the neat idea. is there a workaround that doesn't involve manually editing the stack state?

[danielrbradley]

is there a workaround that doesn't involve manually editing the stack state?

I believe running pulumi refresh should correctly pick up the deletion and correct the state automatically.