Updating just the Pulumi resource name ends up with us having no GitHub resources

[xShteff]

Describe what happened

We noticed that updating the Pulumi resource name for Issue Labels will trigger a replacement update, which is fine, what is not fine is the order the replacement happens.

Let's say we have a label called myRedLabel in Pulumi, which creates a label named Danger in GitHub. If we plan on renaming the Pulumi name to dangerLabel, it will create a label called Danger in GitHub, then it will delete the myRedLabel Pulumi label, which ends up with the Danger label being deleted in GitHub.

The end result is me having a Pulumi stack with a dangerLabel object but no actual Danger label in GitHub.

We've tried using deleteBeforeReplace: true and replaceOnChanges: ["*"] as custom pulumi options but neither have managed to trigger the correct order that would end up with us having an actual Label on GitHub.

I think the fix for this would be to trigger a proper Pulumi replacement, which would then allow us (or have it by default) to delete the item before it being replaced.

Sample program

Start with this:

new github.IssueLabel(`myRedLabel`, {
    repository: "TestRepo",
    name: "Danger",
    color: "ff0000",
    description: "This is a dangerous label"
}, {
    deleteBeforeReplace: true
});

run pulumi up

Then change it to this:

new github.IssueLabel(`dangerLabel`, {
    repository: "TestRepo",
    name: "Danger",
    color: "ff0000",
    description: "This is a dangerous label"
}, {
    deleteBeforeReplace: true
});

run pulumi up

Log output

     Type                        Name                                                       Status              
     pulumi:pulumi:Stack         your-project-name-here                                               
 +   ├─ github:index:IssueLabel  dangerLabel                                                created (2s)            
 -   ├─ github:index:IssueLabel  myRedLabel                                                 deleted (0.55s)         
 
Resources:
    + 1 created
    - 1 deleted 

Affected Resource(s)

I've only identified this with IssueLabels but chances are more would be affected.

Output of pulumi about

Version      3.125.0
Go Version   go1.22.5
Go Compiler  gc

Plugins
KIND      NAME    VERSION
resource  github  6.2.3
language  nodejs  unknown

Host     
OS       darwin
Version  14.5
Arch     arm64

This project is written in nodejs: executable='/Users/alinstefanolaru/.nvm/versions/node/v18.14.2/bin/node' version='v18.14.2'

Current Stack: organization/your-project-name-here/prod

TYPE                                URN
pulumi:pulumi:Stack                 urn:pulumi:prod::your-project-name-here::pulumi:pulumi:Stack::your-project-name-here
pulumi:providers:github             urn:pulumi:prod::your-project-name-here::pulumi:providers:github::github-provider
github:index/issueLabel:IssueLabel  urn:pulumi:prod::your-project-name-here::github:index/issueLabel:IssueLabel::dangerLabel



Found no pending operations associated with prod

Backend        
Name           M-00032
URL            <redacted>
User           alinstefanolaru
Organizations  
Token type     personal

Dependencies:
NAME            VERSION
@pulumi/github  6.2.3
@pulumi/pulumi  3.128.0
@types/node     18.19.43
typescript      5.5.4

I've redacted the Backend URL and project name (:

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[guineveresaenger]

Hi @xShteff - thank you for filing this issue and providing a repro. We're sorry you're encountering this issue and will take a look into it.

[xShteff]

Hi @xShteff - thank you for filing this issue and providing a repro. We're sorry you're encountering this issue and will take a look into it.

No worries, let me know if there is more information needed from my side :)

[guineveresaenger]

Hi @xShteff - so I looked into this via a repro, tried a few things, and unfortunately it turns out you're running into a long-standing issue on how the Pulumi engine understands and treats resource names.

I'll try to summarize.

• Resource names are considered structural. When you change the resource name, the Pulumi engine doesn't know to associate it with the infrastructure for the previous name.
• In the case of GitHub IssueLabels, the provider first checks if this label exists, and then updates the stack (basically a courtesy import due to GitHub's default issue labels). That's why you see a "Create"; but this only affects the stack, not the underlying resource. Normally, your pulumi up would fail here as you'd be trying to create the same resource twice.
• The real label gets deleted because it (not the new name) is still associated with the underlying resource.

The good news here is that this is unlikely to happen to other resources in this provider. The upstream provider documents this courtesy import here and ours behaves the same. I will issue an update to the provider's API docs to this effect.

Additionally, we do offer a workaround for renaming resources. By using the aliases resource option you can issue a new resource name to your stack, and your label won't even need to get deleted and replaced. It would look like this:

After creating the Label with the name myRedLabel, change the name but pass the old name as an alias:

new github.IssueLabel(`dangerLabel`, {
    repository: "TestRepo",
    name: "Danger",
    color: "ff0000",
    description: "This is a dangerous label"
}, {
    aliases: [{ name: "myRedLabel" }]
})

You can even remove the alias the next time you run pulumi up.

I'm going to get that docs info up, and then close this issue as working as expected, but please feel free to re-open if you need.

[mbogh]

This is also an issue for Action Variables and Secrets.

[xShteff]

• In the case of GitHub IssueLabels, the provider first checks if this label exists, and then updates the stack (basically a courtesy import due to GitHub's default issue labels). That's why you see a "Create"; but this only affects the stack, not the underlying resource. Normally, your pulumi up would fail here as you'd be trying to create the same resource twice.
• The real label gets deleted because it (not the new name) is still associated with the underlying resource.

The biggest problem is that in the end the real label doesn't exist despite Pulumi believing it does, and there is no elegant way of continuing updating the stack unless we disable integrity checks.

I'm not quite sure how it works with the current implementation of pulumi-github but when we've fiddled around with custom Pulumi providers we discovered a property called replaces that depending on your changes it would trigger a proper replacement of the object, instead of creating/deleting the old one. (We have an example here https://github.com/LEGO/pulumi-link-mobility-provider/blob/main/src/link-mobility.provider.ts#L94)

Would that be perhaps something worth considering?

(Not sure if this is worth reopening the issue, hopefully we can continue the discussion 🙃 )

[guineveresaenger]

@mbogh could you please file another issue with a repro for those resources? The "regular" behavior that we'd usually see here is that the pulumi up should fail with a message saying you're trying to create a resource that already exists, but this provider in particular has extra logic around a Create. It may be worth it to dig a little further to make this experience more smooth.

@xShteff -

there is no elegant way of continuing updating the stack unless we disable integrity checks.

Is there a reason that pulumi refresh won't work for you here to get your stack state (new resource name, no actual label) unstuck?The resource should get updated (in this case, deleted from the stack, since the label doesn't actually exist) and then you can re-create the label with the new name. I didn't mention this because I was assuming you'd want to avoid a multi-step stack operation.

The best way for us to follow up here is to open a followup issue or re-open this one so that our triage automation can alert us. 😄

[xShteff]

Is there a reason that pulumi refresh won't work for you here to get your stack state (new resource name, no actual label) unstuck?The resource should get updated (in this case, deleted from the stack, since the label doesn't actually exist) and then you can re-create the label with the new name. I didn't mention this because I was assuming you'd want to avoid a multi-step stack operation.

It could work, we use GH Actions to do all these deployments and we would basically have to re-run the workflows when things change. I guess that could work, I just hoped to not have to do that :)

The best way for us to follow up here is to open a followup issue or re-open this one so that our triage automation can alert us. 😄

Got it! Thanks :)

[pulumi-bot]

This issue has been addressed in PR #746 and shipped in release v6.2.5.