resource.consul_service "async" changes after creation

I'm not 100% sure if that's to TF providers fault or simply "the way consul works" but, almost every time I create a consul service (with checks) after the terraform apply, the next terraform plan includes a change with the service check information. Even thought it was already "published" to consul in the first plan/apply setup.

Terraform Version

Terraform v1.5.1 (but it's also problematic on 1.3.x, 1.4.x)
on darwin_amd64

Affected Resource(s)

consul_service

Terraform Configuration Files

resource "consul_service" "service" {
  service_id = "example"
  name       = "cache-foo"
  node       = "cache-foo-node"
  address    = "10.9.9.99"
  port       = 6379

  check {
    check_id = "service:${var.name}"
    name     = "cache-foo"
    notes    = "Service check for service:cache-foo"
    ...
  }
}

Expected Behavior

Nothing should show up after plan/apply since the service check and everything service itself should've been created with the above code.

Actual Behavior

After the first plan/apply (possibly due to some async process on consul's side?) the next terraform plan shows:

 resource "consul_service" "service" {
       ....
+        check {
+           check_id                          = "service:cache-foo"
+           deregister_critical_service_after = "30s"
+           interval                          = "30s"
...
        }
    }

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

terraform plan
terraform apply
wait a few minutes to be sure
terraform plan (without any .TF code change)
See weird "already applied" changes

Important Factoids

What I'm unsure of is if this:

consul persist this async, when the provider performs the create it then performs a ready and by that time (due to some eventual consistency) the check is not yet there thus the apply doesn't persist THAT part to TF state — are there parameters to make those options async persisted? is that the default?
TF provider code doesn't properly read the changes, forgetting to update this block and then in the next read somehow it shows as a *TF provider doesn't "wait" for the change to be fully persisted in the apply time, thus the read happens without the service-check is not returned/ignored

Checking the code for the create part, I don't see any major issues:

https://github.com/hashicorp/terraform-provider-consul/blob/9c5772f607ad26325c6bab96917fb41f875dd621/consul/resource_consul_service.go#L234-L253

Then checking how it is read also, nothing big other than it relies on those values being there in the first place:

https://github.com/hashicorp/terraform-provider-consul/blob/9c5772f607ad26325c6bab96917fb41f875dd621/consul/resource_consul_service.go#L271C1-L344

My money would be on service.Checks being empty in the first "read" during the apply but populated later on further reads:

https://github.com/hashicorp/terraform-provider-consul/blob/9c5772f607ad26325c6bab96917fb41f875dd621/consul/resource_consul_service.go#L302

Finally, what leads me to believe it is a consul "problem" is that the tests do not have this issue. Possibly, a slight delay on replicating and different nodes being the ones to receive the "write" vs "read" requests could. The weird part is why would the service itself be replicated but not the service check...

If that is the case, is there anything specific that can be done to perhaps reduce the likelihood of that happening?

hashicorp / terraform-provider-consul