[BUG] - The LoadBalancer resource has ipv4 and ipv6 set as null in the state after a successful creation

[aittam]

Describe the bug
After creating a Load Balancer resource, the terraform state doesn't contain the ipv4 and ipv6 attributes (see screenshot).

To Reproduce
Steps to reproduce the behavior:

1. Create a LB resource
2. Try to access the ipv4 attribute

resource "vultr_load_balancer" "lb" {

  region              = var.region_id
  label               = "${var.cluster_name}-lb"
  balancing_algorithm = "roundrobin"
  vpc                 = var.vpc_id
  attached_instances  = module.cp_instance.*.id

  health_check {
    path     = "/livez"
    port     = 6443
    protocol = "https"
  }
  forwarding_rules {
    frontend_protocol = "tcp"
    frontend_port     = 6443
    backend_protocol  = "tcp"
    backend_port      = 6443
  }
}

resource "azurerm_dns_a_record" "apps" {
  name                = "*.apps.${var.cluster_name}"
  zone_name           = var.domain
  resource_group_name = "my-rg"
  ttl                 = 300
  records             = [vultr_load_balancer.lb.ipv4]
}

Expected behavior
Both ipv4 and ipv6 attributes to be populated correctly.

Screenshots

Desktop (please complete the following information where applicable:

• OS: MacOS 15.7.2
• Terraform v1.14.0
• Provider version v2.27.1

Additional context

Rerunning terraform a second time fetch the informations correctly.

As a workaround we can use a data that depends on the LB resource and collect the informations with a second API call, but that can still potentially fail if it's a timing issue.

[optik-aper]

I haven't yet been able to reproduce this on new load balancers and the read/set code for those fields hasn't been changed. I think the issue stems from something getting held up on the vultr platform which may well occur again. I could make the wait state checks include the IP fields as well as the status, but I think this should probably become a bug on vultr support. Ultimately, it's a computed field, though, so it shouldn't affect the underlying resource and will just need a state refresh once the IPs start returning from the API.