No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

More than once I have ended up in this situation, when a deployment goes wrong and the resource exists in Azure but Pulumi thinks the deployment fails so it doesn’t create the resource in the stack state.

How can I import these resources into the state, so Pulumi stops trying to re-create them?

This should help: <https://www.pulumi.com/blog/adopting-existing-cloud-resources-into-pulumi/#adopting-existing-resources>

Interesting, didn’t know about this. Thanks!

But it doesn’t seem 100% appropriate.. I mean, these are resources that Pulumi itself created.

The fact that they are not in the stack should be addressed with refresh rather than specifying in code that they should be imported.

Seems weird to have to go and change the code to account for an inconsistent state.

I agree, unfortunately I think that's also a problem in TF. I've seen deployments "fail" (but not fail) and then the state is inconsistent.
So you either have to manually edit the state file or do the import. :disappointed:

depends, are you using the service or a storage account you manage?
You can get your state file either way using <https://www.pulumi.com/docs/reference/cli/pulumi_stack_export/>

OK, will check it out! Thanks for the quick response! :thumbsup:

The problem is that if the creation API call fails, there’s no obvious way to know that the actually created resource is ours. I suppose we _could_ have some heuristics but they may be hard to get right across all providers.