Assist users in recovering resources that may have been created despite errors

[thomas11]

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

There are cases where Create seemingly fails but the resource is actually created, at least partly. This can be due to network issues or internal issues of the cloud provider. An example is pulumi/pulumi-azure-native#3200, where the Azure response was "504 Gateway timeout". If such resources are explicitly named or are singletons, subsequent Pulumi up's will fail. If they are not, orphaned resources are created.

Currently, such resources are absent from Pulumi state. For cases like the one linked above, it would be useful if they were recorded as "probably failed to create but might exist". Then, on the next up, the engine could prompt the user that they might want to import them, or refresh if that was extended to cover such resources.

[danielrbradley]

Discussed this as part of the linked issue above. We do already have the partial state mechanism however there were two factors at play which could cause it not to work:

1. There was an error while trying to construct the partial state which resulted in a normal error being returned instead of a partial state error.
2. The provider didn't have cancellation support so would not shut down gracefully and return a partial error.

I think we could re-scope this to returning the partial state immediately after the create has started to avoid situations where there's interruptions causing the partial error not to be returned. This would likely be implemented an additional request that the provider can make to the engine with the initial state from a creation. This would allow the engine to write the partial state as a placeholder in the checkpoint until the final state is recieved - making the partial state creation more reliable and less likely to loose data.

[Frassle]

I think we could re-scope this to returning the partial state immediately after the create has started to avoid situations where there's interruptions causing the partial error not to be returned.

#5210?

[danielrbradley]

@Frassle yes, I think that's the same core issue, but looks like it stalled on the variance between clouds where we can't always know the id up-front. Hence, an optional early back-channel would be a nicer approach, if possible.