`meraki.networks.VlanProfiles` not correctly detecting diff for `vlanNames`

[zbuchheit]

Describe what happened

Whe attempting to use the meraki.networks.VlanProfiles resource, it is not correctly detecting a diff on the vlanNames field for the resource when there is a change. I am able to import the resource, add a field to vlanNames, and expect a diff but pulumi shows no changes. The equivalent in TF using the upstream provider works fine.

Sample program

I can provide a full example on a call but essentially the resource looks like the following

const vlans = new meraki.networks.ApplianceVlans("vlans", {
  networkId: network.id,
  applianceIp: "192.168.2.1",
  vlanId: "2",
  subnet: "192.168.2.0/24",
  name: "guest",
  dhcpHandling: "Do not respond to DHCP requests",
  dnsNameservers: "upstream_dns",
  dhcpLeaseTime: "1 day",
  dhcpBootOptionsEnabled: false,
});

const vlanProfiles = new meraki.networks.VlanProfiles(
  "vlan-profiles",
  {
    networkId: network.id,
    name: "Default Profile",
    iname: "Default",
    vlanNames: [
      {
        name: "default",
        vlanId: "1",
      },
      {
        name: vlans.name, //This should trigger a diff to add
        vlanId: vlans.vlanId, //This should trigger a diff to add
      },
    ],
    vlanGroups: [],
  },
  {
    dependsOn: [vlans],
  }
);

Log output

N/A

Affected Resource(s)

No response

Output of pulumi about

CLI          
Version      3.121.0
Go Version   go1.22.4
Go Compiler  gc

Plugins
KIND      NAME    VERSION
resource  meraki  0.2.5
language  nodejs  unknown

Host     
OS       darwin
Version  14.2.1
Arch     arm64

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

Current Stack: zbuchheit-pulumi-corp/meraki-org-policy-groups-ts/dev

TYPE                                                           URN
pulumi:pulumi:Stack                                            urn:pulumi:dev::meraki-org-policy-groups-ts::pulumi:pulumi:Stack::meraki-org-policy-groups-ts-dev
pulumi:providers:meraki                                        urn:pulumi:dev::meraki-org-policy-groups-ts::pulumi:providers:meraki::default_0_2_5_github_/api.github.com/pulumi/pulumi-meraki
meraki:networks/base:base                                      urn:pulumi:dev::meraki-org-policy-groups-ts::meraki:networks/base:base::base-network
meraki:networks/applianceVlansSettings:ApplianceVlansSettings  urn:pulumi:dev::meraki-org-policy-groups-ts::meraki:networks/applianceVlansSettings:ApplianceVlansSettings::vlan-settings
meraki:networks/applianceVlans:ApplianceVlans                  urn:pulumi:dev::meraki-org-policy-groups-ts::meraki:networks/applianceVlans:ApplianceVlans::vlans
meraki:networks/vlanProfiles:VlanProfiles                      urn:pulumi:dev::meraki-org-policy-groups-ts::meraki:networks/vlanProfiles:VlanProfiles::vlan-profiles

Found no pending operations associated with dev

Backend        
Name           pulumi.com
URL            https://app.pulumi.com/zbuchheit-pulumi-corp
User           zbuchheit-pulumi-corp
Organizations  zbuchheit-pulumi-corp
Token type     personal

Dependencies:
NAME            VERSION
@pulumi/meraki  0.2.5
@pulumi/pulumi  3.122.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).

[VenelinMartinov]

Thanks for the report and the repro here @zbuchheit!

I've had an initial look at this and have confirmed your observations about the lack of diff there.

Interestingly if I change another property on the resource the diff is correctly shown:

    ~ meraki:networks/vlanProfiles:VlanProfiles: (update)
        [id=L_686235993220612994]
        [urn=urn:pulumi:dev::meraki_97::meraki:networks/vlanProfiles:VlanProfiles::vlan-profiles]
        [provider=urn:pulumi:dev::meraki_97::pulumi:providers:meraki::default_0_2_5_github_/api.github.com/pulumi/pulumi-meraki::e43ebd02-182f-448b-9005-34cfdff6efd8]
      ~ iname    : "Default" => "Default1"
      ~ vlanNames: [
            [0]: {
                    name  : "default"
                    vlanId: "1"
                }
          + [1]: {
                  + name  : "guest"
                  + vlanId: "2"
                }
          + [2]: {
                  + name  : "voice"
                  + vlanId: "3"
                }
        ]

GRPC logs:

```json { "method": "/pulumirpc.ResourceProvider/Diff", "request": { "id": "L_686235993220612994", "urn": "urn:pulumi:dev::meraki_97::meraki:networks/vlanProfiles:VlanProfiles::vlan-profiles", "olds": { "iname": "Default", "isDefault": true, "name": "vlan-profiles-4e760d2", "networkId": "L_686235993220612994", "vlanGroups": [], "vlanNames": [ { "name": "default", "vlanId": "1" } ] }, "news": { "iname": "Default", "name": "vlan-profiles-4e760d2", "networkId": "L_686235993220612994", "vlanGroups": [], "vlanNames": [ { "name": "default", "vlanId": "1" }, { "name": "guest", "vlanId": "2" } ] }, "oldInputs": { "iname": "Default", "name": "vlan-profiles-4e760d2", "networkId": "L_686235993220612994", "vlanGroups": [], "vlanNames": [ { "name": "default", "vlanId": "1" } ] } }, "response": { "changes": "DIFF_NONE" }, "metadata": { "kind": "resource", "mode": "client", "name": "meraki" } } ```

This certainly looks like a bridge issue - the change seems to be very much ignored here.

[VenelinMartinov]

A workaround here would be to update another property along with the vlanNames, run up and revert the other change.

[VenelinMartinov]

Confirmed this does not repro in TF:

```hcl resource "meraki_networks_appliance_vlans" "vlans" { network_id = meraki_networks.base_network.id appliance_ip = "192.168.2.1" id = "2" subnet = "192.168.2.0/24" name = "guest" dhcp_handling = "Do not respond to DHCP requests" dns_nameservers = "upstream_dns" dhcp_lease_time = "1 day" dhcp_boot_options_enabled = false depends_on = [meraki_networks_appliance_vlans_settings.vlan_settings] } resource "meraki_networks_vlan_profiles" "vlan_profiles" { network_id = meraki_networks.base_network.id iname = "Default" vlan_names = [ { name = "default" vlan_id = "1" }, { name = meraki_networks_appliance_vlans.vlans.name vlan_id = meraki_networks_appliance_vlans.vlans.id } ] vlan_groups = [] depends_on = [meraki_networks_appliance_vlans.vlans] } ```

But it looks as if the TF plan is returning the wrong planned state (but it's likely on our side, as this does not repro in TF)

``` 0.021s DiffWithContext rh.terraformResourceName=meraki_networks_vlan_profiles 0.024s plannedStateValue=tftypes.Value{ typ: tftypes.Object{ AttributeTypes: { "iname": tftypes.primitive{ name: "String", _: nil, }, "is_default": tftypes.primitive{ name: "Bool", _: nil, }, "name": tftypes.primitive{ name: "String", _: nil, }, "network_id": tftypes.primitive{ name: "String", _: nil, }, "vlan_groups": tftypes.Set{ ElementType: tftypes.Object{ AttributeTypes: { "name": tftypes.primitive{ name: "String", _: nil, }, "vlan_ids": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, _: nil, }, "vlan_names": tftypes.Set{ ElementType: tftypes.Object{ AttributeTypes: { "adaptive_policy_group": tftypes.Object{ AttributeTypes: { "id": tftypes.primitive{ name: "String", _: nil, }, "name": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, "name": tftypes.primitive{ name: "String", _: nil, }, "vlan_id": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, _: nil, }, }, OptionalAttributes: {}, _: nil, }, value: map[string]tftypes.Value{ "iname": { typ: tftypes.primitive{ name: "String", _: nil, }, value: "Default", }, "is_default": { typ: tftypes.primitive{ name: "Bool", _: nil, }, value: bool(true), }, "name": { typ: tftypes.primitive{ name: "String", _: nil, }, value: "vlan-profiles-4e760d2", }, "network_id": { typ: tftypes.primitive{ name: "String", _: nil, }, value: "L_686235993220612994", }, "vlan_groups": { typ: tftypes.Set{ ElementType: tftypes.Object{ AttributeTypes: { "name": tftypes.primitive{ name: "String", _: nil, }, "vlan_ids": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, _: nil, }, value: []tftypes.Value{ }, }, "vlan_names": { typ: tftypes.Set{ ElementType: tftypes.Object{ AttributeTypes: { "adaptive_policy_group": tftypes.Object{ AttributeTypes: { "id": tftypes.primitive{ name: "String", _: nil, }, "name": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, "name": tftypes.primitive{ name: "String", _: nil, }, "vlan_id": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, _: nil, }, value: []tftypes.Value{ { typ: tftypes.Object{ AttributeTypes: { "adaptive_policy_group": tftypes.Object{ AttributeTypes: { "id": tftypes.primitive{ name: "String", _: nil, }, "name": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, "name": tftypes.primitive{ name: "String", _: nil, }, "vlan_id": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, value: map[string]tftypes.Value{ "adaptive_policy_group": { typ: tftypes.Object{ AttributeTypes: { "id": tftypes.primitive{ name: "String", _: nil, }, "name": tftypes.primitive{ name: "String", _: nil, }, }, OptionalAttributes: {}, _: nil, }, value: nil, }, "name": { typ: tftypes.primitive{ name: "String", _: nil, }, value: "default", }, "vlan_id": { typ: tftypes.primitive{ name: "String", _: nil, }, value: "1", }, }, }, }, }, }, } ```

from https://github.com/pulumi/pulumi-terraform-bridge/blob/18db7c57211af0eb7dfa26a70b145edc4d33a88f/pf/tfbridge/provider_diff.go#L95

[VenelinMartinov]

Built out a repro in the bridge: https://github.com/pulumi/pulumi-terraform-bridge/pull/2168

[VenelinMartinov]

Opened https://github.com/pulumi/pulumi-terraform-bridge/issues/2170 for the bridge bug, will continue the investigation there.

[VenelinMartinov]

Update here, this looks like an issue in the bridge internals and it doesn't look pretty. We seem to be mishandling Computed set nested values in the PF bridge.

[pulumi-bot]

This issue has been addressed in PR #109 and shipped in release v0.2.6.

[zbuchheit]

I am still seeing this behavior in v0.2.6, I recommend we re-open this issue

[zbuchheit]

confirmed this is resolved and we can close