Day 2 operations report success but make no changes in infoblox, resulting in an invalid object returned where the values are in conflict

[jskirde]

In the latest version (2.10.0) of the infoblox provider, there are still numerous resources that do not accurately change when inputs that used to calculate them have changed. There seems to be a complete lack of the forceNew attribute used in the schema to accurately force the recreation of such objects.
As an example, changing the cidr used for an A record should delete and re-create the record on a new IP in the correct cidr range but instead returns back the same record with an updated Terraform state reflecting the new unused cidr.
Initial code:

terraform {
  required_providers {
    infoblox = {
      source  = "infobloxopen/infoblox"
      version = "2.10.0"
    }
  }
}

resource "infoblox_a_record" "test1" {
  fqdn         = "test1.mydomain.com"
  cidr         = "10.0.0.0/24" # Change this line later
  network_view = "default"
  comment      = "Test record"
  ext_attrs    = jsonencode({})
}

... perform a terraform apply

terraform {
  required_providers {
    infoblox = {
      source  = "infobloxopen/infoblox"
      version = "2.10.0"
    }
  }
}

resource "infoblox_a_record" "test1" {
  fqdn         = "test1.mydomain.com"
  cidr         = "10.1.0.0/24"
  network_view = "default"
  comment      = "Test record"
  ext_attrs    = jsonencode({})
}

output "test1" {
  value = infoblox_a_record.test1
}

At the conclusion of this, your DNS A record will still be resolving to an address in 10.0.0.0/24!
Recommendation: Consider all inputs that may necessitate the creation of new objects instead of updates (at least resource_infoblox_a_record, resource_infoblox_cname_record, resource_infoblox_network and resource_infoblox_network_container!)

[mib-unimelb]

Can confirm we are also having this issue and consider it a serious bug.