Pulumi refresh does not detect an external change in the VCL Service name and that it has been deactivated.

[JiriKovar]

Describe what happened

We have a several Fastly VCL services managed by ServiceVcl definitions that are already in the Pulumi stack (everything is up and running for some time).

A service name was changed outside of the Pulumi automation and it was deactivated due to reasons unrelated to this issue.

We wanted to rollback these changes with Pulumi, but the next pulumi up command with refresh flag did not notice any of these changes. The specific command is as follows: pulumi up --refresh --yes --skip-preview The same behaviour was also observed with the command pulumi preview --refresh = no changes detected.

Then we have decided to test that the overall solution is working by manually creating a new version of the VCL Service through the Fastly UI, deleting a random part of the definition (it was an http header), activating it and running the aforementioned command again. At that point, it detected the missing part, added it back and activated the service, however the change in the name of the service has remained undetected and therefor was still not fixed.

Sample program

const serviceVcl = new fastly.ServiceVcl(
  name,
  {
    defaultTtl: 10,
    backends,
    domains: domains,
    snippets,
    conditions,
    loggingBlobstorages,
    headers,
    requestSettings,
    gzips,
    dictionaries: dictionaries,
    acls,
    dynamicsnippets: [],
  },
  {
    ignoreChanges: ['versionComment', 'dynamicsnippets'],
    import: args.importId ?? '',
  },
);

Log output

No response

Affected Resource(s)

No response

Output of pulumi about

CLI Version 3.131.0 Go Version go1.23.0 Go Compiler gc

Plugins KIND NAME VERSION language nodejs unknown

Host OS Microsoft Windows 11 Enterprise Version 10.0.22631 Build 22631 Arch x86_64

This project is written in nodejs: executable='C:\Program Files\nodejs\node.exe' version='v20.17.0'

TYPE URN pulumi:providers:fastly urn:pulumi:fb94b::on_demand_client::pulumi:providers:fastly::default_8_11_0 fastly:index/serviceVcl:ServiceVcl urn:pulumi:fb94b::on_demand_client::fastly:index/serviceVcl:ServiceVcl::fb94b-draft fastly:index/serviceDictionaryItems:ServiceDictionaryItems urn:pulumi:fb94b::on_demand_client::fastly:index/serviceVcl:ServiceVcl$fastly:index/serviceDictionaryItems:ServiceDictionaryItems::allowed_CORS_domains_fb94b-draft

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 @JiriKovar - thank you for filing this issue. We're sorry you're having trouble.

It is possible that you are running into this upstream behavior which occurs when a Service is deactivated outside of Pulumi/Terraform. It appears the provider does not actually detect these changes and carries on as before.

The suggestion in that issue is to run refresh twice, so you could give that a try.

I'm not sure what to tell you about the name field - what happens to an active Service when you change the name in the pulumi program? It may be a red herring here.

If you continue to get stuck here, could you please provide us with a minimally complete repro of this behavior, including step-by-step instructions to mirror the events in the Fastly console?

[JiriKovar]

Hi @guineveresaenger,

thanks for looking into this. We are actually migrating from the Terraform to the Pulumi and please know that we have not faced this issue in the Terraform. Also, we have attempted to run the refresh + up many times over while debugging the issue and it did not help. Therefor, unless there is a reason that refresh -> refresh -> up would bring a different result compared to the refresh -> up -> refresh -> up, I don't think it could help (and if it could, I would very much like to know why). Anyway, I will test that as soon as I have a bit of time to spare. Thank you!

As for the name, when we change that in the pulumi program compared to what is in the state, the name gets updated correctly.

As for the minimal repro, I believe that I wont be much of a help here - you need to specify only a name and a single domain to the ServiceVcl configuration and the rest is to connect the provider to a fastly account (I sadly cannot give you an access to our account) and then causing a drift in the Fastly once its created. So, here is the best I can give you:

const serviceVclResource = new fastly.ServiceVcl("MyServiceNameFromPulumi", {
    domains: [{
        name: "my-pulumi-provider-test.global.ssl.fastly.net",
    }],
});

[guineveresaenger]

Hi @JiriKovar - thank you for your response.

We do have a Fastly test account, so if you could please clarify - we should see this behavior when:

1. A ServiceVCL is created via pulumi
2. Its name field is changed, outside of Pulumi management
3. pulumi refresh fails to report any changes to the name of the resource
4. The example program in your comment above this one is sufficient to cause this behavior.

Did you activate the Service manually before importing it? Is that something you could give a try?

Could you also elaborate on

however the change in the name of the service has remained undetected and therefor was still not fixed. I understand this is about a new, manually created service. Did you also have a different name for this service?

Please do let us know if you can report anything new here.

[JiriKovar]

Hi, yes, that list of steps is sufficient to reproduce the issue with the name.

Whether the service is manually activated or not does not matter in case of the service name drift detection.

however the change in the name of the service has remained undetected and therefor was still not fixed. I understand this is about a new, manually created service. Did you also have a different name for this service?

Not really - this is the case for the service that has been imported and managed by pulumi for several versions.

[VenelinMartinov]

Hey @JiriKovar, the issue does not reproduce for me. pulumi refresh successfully detects drift in both the service name and the domain name.

esc run providers.all -i -- pulumi refresh
Warning: Referring to an environment name ('providers.all') without a project is deprecated.
Please use 'pulumi/default/providers.all' or 'default/providers.all' instead.
Previewing refresh (dev)

View in Browser (Ctrl+O): https://app.pulumi.com/pulumi/fastly_629/dev/previews/80297ccd-6ad1-4b9e-a004-fd082d4eadd9

     Type                        Name                     Plan       Info
     pulumi:pulumi:Stack         fastly_629-dev
 ~   └─ fastly:index:ServiceVcl  MyServiceNameFromPulumi  update     [diff: ~domains,name]

Resources:
    ~ 1 to update
    1 unchanged

Do you want to perform this refresh?
No resources will be modified as part of this refresh; just your stack's state will be.
 details
  pulumi:pulumi:Stack: (same)
    [urn=urn:pulumi:dev::fastly_629::pulumi:pulumi:Stack::fastly_629-dev]
    ~ fastly:index/serviceVcl:ServiceVcl: (update)
        [id=wIfm38Zb2oE1Q2R52BUYW7]
        [urn=urn:pulumi:dev::fastly_629::fastly:index/serviceVcl:ServiceVcl::MyServiceNameFromPulumi]
        [provider=urn:pulumi:dev::fastly_629::pulumi:providers:fastly::default_8_11_1::df9b32c2-9565-477f-b7cf-3307cee7afdd]
      ~ domains: [
          ~ [0]: {
                  ~ name: "my-pulumi-provider-test.global.ssl.fastly.net" => "1my-pulumi-provider-test.global.ssl.fastly.net"
                }
        ]
      ~ name   : "MyServiceNameFromPulumi-d3f9181" => "MyServiceNameFromPulumi-d3f9181a"

Do you want to perform this refresh?
No resources will be modified as part of this refresh; just your stack's state will be.
  [Use arrows to move, type to filter]
  yes
> no
  details

Which version of the fastly provider are you using? Can you please try updating that to the latest version and retrying?

[JiriKovar]

Hello @VenelinMartinov,

Unfortunatelly I have just reproduced the issue both service name drift and deactivated status were not detected. I'm using the latest fastly provider version. Here is my minimal step by step repro:

• pulumi new typescript -f -y -g
• copy paste this code to the index.ts

  
  import { ServiceVcl } from '@pulumi/fastly';

// Define the Fastly service new ServiceVcl('myFastlyService', { name: 'jiris', backends: [ { address: 'example.com', name: 'example-backend', port: 80, }, ], domains: [ { name: 'jiris.global.ssl.fastly.net', }, ], defaultHost: 'jiris.global.ssl.fastly.net', });

* add `"@pulumi/fastly": ">=8.12.0"` to the package.json
* pulumi install
* pulumi stack init -s jiris
* pulumi config set --secret fastly:apiKey \<FastlyApiKey\>
* pulumi up
* manually change the service name in the manage.fastly.com portal and / or deactivate the service
* pulumi refresh --diff --skip-preview --non-interactive
* pulumi up
* the last up results as follows:
![Image](https://github.com/user-attachments/assets/41e2c997-54d8-41d3-9e4c-c0b9f0fb5fc7)
* the service in the manage.fastly.com portal still in the state as after my manual changes:
![Image](https://github.com/user-attachments/assets/f7a276fc-22ab-4a62-ab41-c2d6f3b2df95)

That being said, running the refresh twice caused the service name drift to be detected, but the service remains deactivated. Also, FYI, setting the [activate](https://www.pulumi.com/registry/packages/fastly/api-docs/servicevcl/#activate_nodejs) explicitly to `true`, changes nothing.

Overall I guess that the service name might be caused by some cache on the Fastly, so if you decide not to pursue this issue, I can understand that (after all, the next time we run refresh + up, it gets fixed and the service name has no effect on whether the service works or not), but the deactivated status is quite an issue for us in these cases. And in case of the deactivation status, the behaviour is consistent no matter how many refreshes we run.

[guineveresaenger]

hi @JiriKovar - thank you for the followup and detailed steps. We'll take another look when we can.