Provider bug errors with Resource Pools

[michaelbhughes]

Summary

We are on the Apstra provider version v0.53.2 and are running into weird provider errors when working with resource pools. The desired changes always get implemented correctly within Apstra, but at the end of the apply we get a provider error. See the Error Examples below for what error we are seeing. In both examples, we were creating a fresh blueprint and its resources from scratch.

Running another plan/apply refreshes the state and does not encounter the error again.

These errors aren't blocking us, but we would like to flag them so you are aware of them. Perhaps you'll be able to figure out what is triggering the errors.

Error Examples

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ apstra_asn_pool.asn_pools["tf_kmlpbcnu_pod_03_ip_fabric_global_asn"],
│ provider "provider[\"registry.terraform.io/juniper/apstra\"]" produced an
│ unexpected new value: .ranges: planned set element
│ cty.ObjectVal(map[string]cty.Value{"first":cty.NumberIntVal(4.200000005e+09),
│ "last":cty.NumberIntVal(4.200000005e+09),
│ "status":cty.UnknownVal(cty.String), "total":cty.UnknownVal(cty.Number),
│ "used":cty.UnknownVal(cty.Number),
│ "used_percentage":cty.UnknownVal(cty.Number)}) does not correlate with any
│ element in actual.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to
│ apstra_ipv6_pool.ipv6_pools["tf_fabric_external_ipv6_kmlpbcnu_pod_03"],
│ provider "provider[\"registry.terraform.io/juniper/apstra\"]" produced an
│ unexpected new value: .subnets: planned set element
│ cty.ObjectVal(map[string]cty.Value{"network":cty.StringVal("2001:568:FFE2:4e6:0:0:0:0/64"),
│ "status":cty.UnknownVal(cty.String), "total":cty.UnknownVal(cty.Number),
│ "used":cty.UnknownVal(cty.Number),
│ "used_percentage":cty.UnknownVal(cty.Number)}) does not correlate with any
│ element in actual.
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.

[chrismarget-j]

Thanks @michaelbhughes,

I have an idea about what's going on here: We're setting the values and then reading everything back from the API to collect usage stats, etc...

When Apstra is particularly busy (hard to duplicate in testing) our read may be executed before everything is "settled" in Apstra's database.

We've worked around this kind of issue in other resources, but didn't realize it might crop up in this one.

As you've noticed, it is safe to proceed when this error pops up.

[chrismarget-j]

AOS-46273

[chrismarget-j]

I'd like to revisit this problem when we next meet.

Closing this issue for now because I don't think there's much we can do about it from the client side.