cloudflare:index:ZeroTrustAccessApplication error: objectEncoder failed on property "cors_headers"

[AMKamel]

Describe what happened

After upgrading to major cloudflare provider version 6.1.1 and updating the code to handle backward incompatibility issues when I run pulumi up and on preview stage, I see this error:

cloudflare:index:ZeroTrustAccessApplication error: objectEncoder failed on property "cors_headers"

Sample program

        this.accessApplication = new cloudflare.ZeroTrustAccessApplication(
            `${name}-cfAccessApplication`,
            {
                name: args.fqdn,
                accountId: args.accountId,
                zoneId: args.zoneId,
                domain: args.fqdn,
                type: 'self_hosted',
                sessionDuration: '24h',
            },
            {
                parent: this,
                aliases: [
                    interpolate`urn:pulumi:${args.fqdn}::deployment::cf:access:application$cloudflare:index/accessApplication:AccessApplication::${args.fqdn}-cfAccessApplication`,
                ],
            },
        );

Log output

Diagnostics: cloudflare:index:ZeroTrustAccessApplication (cfAccessApplication-0): error: objectEncoder failed on property "cors_headers": Expected an Object PropertyValue, found [] ("{[]}")

Affected Resource(s)

No response

Output of pulumi about

pulumi about
CLI
Version      3.165.0
Go Version   go1.24.2
Go Compiler  gc

Plugins
KIND      NAME    VERSION
language  nodejs  3.165.0

Host
OS       arch
Version  "rolling"
Arch     x86_64

This project is written in nodejs: executable='/home/abukamel/.nvm/versions/node/v22.15.0/bin/node' version='v22.15.0'

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).

[t0yv0]

Thanks for reporting this @AMKamel - it appears this is a cloudflare provider issue so I transferred here. Since your program does not specify cors_headers I suspect the value is coming from the statefile. Would you be able to work around the problem by editing the statefile to remove corsHeaders from it (pulumi stack export/import commands)?

To fix the original issue, it is likely that there is a bug in the migration of state for cloudflare.ZeroTrustAccessApplication between v-prev and 6.1.1. It would be really helpful if you could provide a more self-contained example of the program before and after that reproduces the failure (program1 -> pulumi up -> program 2 -> pulumi up). Thank you!

[AMKamel]

After upgrading to 6.2 I thought it would be solved, so I tried, but got an error:

error: [pf/tfbridge] Error calling EncodePropertyMap: objectEncoder failed on property "cors_headers": Expected an Object PropertyValue, found [] ("{[]}")

[t0yv0]

@AMKamel still would appreciate a repro per the comment above to get us started. We can close the issue once we are confident we have a fix that fixes a known repro.

[AMKamel]

I tried to reproduce in a new program but no errors and it worked.

With help of AI agent, it told me maybe state old output or input has corsHeaders set to an array [], update the state manually to remove it and try again.

I exported,then removed corsHeaders from stack outputs then import and pulumi up, and it worked.

I hope this can help you have a fix instead of the need to do manual state edit for all old stacks.

@t0yv0

AI Solution:

Steps to Modify Pulumi Stack for Cloudflare ZeroTrustAccessApplication Export Stack State: Ensure you have a fresh export of your stack:

pulumi stack export --file current_problem_state.json CRITICAL: Backup State File: Make a backup copy of current_problem_state.json before editing. Edit State File: Open current_problem_state.json in a text editor. Locate Resource: Locate the resource with "type": "cloudflare:index/zeroTrustAccessApplication:ZeroTrustAccessApplication" and the URN that matches your problematic application (e.g., ...islamqa-forms-admin-testing.zadapps.info-cfAccessApplication...). Identify corsHeaders: Within this resource's definition, you'll find "inputs" and "outputs" sections. Look for "corsHeaders": [] in both inputs and outputs. Modify corsHeaders: Carefully delete the entire "corsHeaders": [] line from both the inputs and outputs sections. Alternatively, you could try changing [] to null, so it becomes "corsHeaders": null. However, complete removal might be cleaner if the provider now treats absence as "not set". Save Modified File: Save the modified file (e.g., as modified_state.json). Import Corrected State: Import the corrected state: bash Copy Code pulumi stack import --file modified_state.json Verify Pulumi Code: Ensure your Pulumi component code (e.g., cf-access-application/index.ts) still has ignoreChanges: ["corsHeaders"] and that corsHeaders is not set in the inputs (as per your last change). Apply Changes: Run pulumi up.

[AMKamel]

The Ideal "Automation" / Long-Term Solutions:Provider Fix (Most Important): The @pulumi/cloudflare provider should be updated to:Correctly migrate old states that might have corsHeaders: [].Or, allow ignoreChanges to bypass the problematic property during state reading.Ensure it doesn't write corsHeaders: [] into the state if undefined is provided in the code, instead treating undefined as "not set" or a valid null-like value. I strongly urge you to report this issue to the pulumi-cloudflare GitHub repository with all the details we've gathered. This will help them fix it for everyone.

[wrbbz]

Yeah. The issue persists when upgrading from 5.x.x to 6.x.x. As @AMKamel suggested, manual changes of stack works well. Or, you can explicitly set corsHeaders: {} in ZeroTrustAccessApplicationArgs.

The similar error could be met on creation of Application with predefined policies. It is also due to the changes of policies object. In 5.x.x version it was just an array of id's, however, now it is an array of objects. Thus, something like this:

"policies": [
  "e47b6b82-ff16-4a57-92f0-0b9486e548f4"
],

should be transformed in stack to:

"policies": [
  {
    "id": "e47b6b82-ff16-4a57-92f0-0b9486e548f4"
  }
],

[bruno-espino]

Can confirm, also hit the issue upgrading to 6.2. For both cors_headers and policies array

[t0yv0]

Thank you for the confirmations! I think we will need custom state migrations to fix these upgrade stories, for each affected resource. In the meanwhile it's always helpful if you can attach an exact minimal repro: program before upgrade, version before and version after the provider. We can use those as test cases to verify the migrations work.