[Bug] Error 400 resource_already_exists_exception when replacing an index

[BardiaN]

Describe the bug
Changing mapping_coerce on an index's mapping will trigger a replace. But the provider tries first to create the index which is not possible as it already exists.
I even tried adding create_before_destroy = false which is the default terraform behavior but it didn't work as expected.

lifecycle {
    create_before_destroy = false
  }

To Reproduce
Steps to reproduce the behavior:

1. TF configuration used

resource "elasticstack_elasticsearch_index" "index" {
  name                = "index-one"

  mappings = jsonencode({
    properties = {
      name = {
        type = "text"
      }
   }
   })
  number_of_shards   = 1
  number_of_replicas = 1
  search_idle_after  = "20s"
  mapping_coerce     = false
}

2. terraform apply to create the index
3. Then change the mapping_coerce to true
4. terraform apply to apply the coerce
5. The plan will look like this :

Plan: 1 to add, 0 to change, 1 to destroy.

6. Then enter yes to apply.
7. Provider will try to create the resource first which causes the error:

elasticstack_elasticsearch_index.index: Creating...

│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╷
│ Error: Unable to create index: index
│ 
│   with elasticstack_elasticsearch_index.index,
│   on ./elastic-search.tf line 3, in resource "elasticstack_elasticsearch_index" "index":
│    3: resource "elasticstack_elasticsearch_index" "index" {
│ 
│ Failed with: {"error":{"root_cause":[{"type":"resource_already_exists_exception","reason":"index
│ [index/<ID>] already
│ exists","index_uuid":"<ID>","index":"index"}],"type":"resource_already_exists_exception","reason":"index
│ [index/<ID>] already
│ exists","index_uuid":"<ID>","index":"index"},"status":400}
╵

Expected behavior
The provider should respect create_before_destroy. In this case it means it has to destroy the index first and then create the new one.

Versions (please complete the following information):

• OS: Mac OS Sequoia 15.1 (24B83)
• Terraform v1.8.5
• Provider version 0.11.12
• Elasticsearch Version 7.17

Additional context

I also tried using alias, had the same result

[tobio]

I'm struggling to reproduce this behaviour.

Following the repro steps exactly fails at 4. since deletion_protection has not been set on the index. Have you updated the TF definition to set that option?

Are you able to provide TF debug logs TF_LOG=debug terraform apply for when the recreation fails?

The provider should respect create_before_destroy

This is a Terraform level option, the provider doesn't have any influence over how this is implemented. The Terraform CLI will destroy a resource prior to creating it without this set (like you mention), and there's not anything the provider can do to impact that.

[tobio]

I think this is likely a documentation issue. I suspect the workflow to reproduce this is:

• Create the index
• Run a background job which constantly indexes documents into the index
• Update the mapping_coerce attribute triggering a destroy/create

There's not much the provider can do in this scenario outside of improving the error messaging/documentation. The customer needs to stop the indexing load (or prevent automatic index creation in the cluster) so the index isn't recreated by Elasticsearch before the provider can recreate it.