This message was deleted.

I've always wondered why something like this doesn't exist. I don't immediately see a strong reason why this wouldn't work.

Technically - it would require pulumi to make queries that it currently doesn't have for all resource types probably. On the other hand - with things like kubernetes and azure - it typically gets enough information in the error message to be able to redeclare its own configuration on top of the existing information (azure has the id of the resource provided in the error, kubernetes will allow it easily to extract any needed information to adopt it in the stack). For instance:

├─ dep:components:cache                            Cache
 +         │  └─ azure-native:cache:RedisEnterprise            log-region-redisEnterprise-redis             **creating failed**     1 error
....
azure-native:cache:RedisEnterprise (log-region-redisEnterprise-redis):
    error: Code="Failed" Message="The async operation failed." AdditionalInfo=[{"endTime":"2021-06-30T13:23:52.6943019+00:00","id":"/subscriptions/<sub>/providers/Microsoft.Cache/locations/Region/operationsStatus/<guid>","name":"<guid>","startTime":"2021-06-30T13:16:25.9968294+00:00","status":"Failed"}]

and it's actually created, leading to the next up showing:

dep:components:cache                            Cache
 +         │  └─ azure-native:cache:RedisEnterprise            log-region-redisEnterprise-redis                  **creating failed**     1 error
......
 azure-native:cache:RedisEnterprise (log-region-redisEnterprise-redis):
    error: cannot create already existing resource '/subscriptions/<sub>/resourceGroups/<rg_name>_region/providers/Microsoft.Cache/redisEnterprise/log-redis'

Meaning I have to either import this into the stack (with a fairly complicated and deep URN), or delete it and try again (and redis takes forever to deploy in azure, probably hence the error above). Having

pulumi adopt

run against the stack would easily be able to pick it up and ensure that whatever configuration differences that might exist get ironed out without having to figure out the deep URN path to the resource I don't yet have in the stack..

why not just use the pulumi.Import() resource option when creating a "new" resource?