When changing a description of the default queue of a cluster, the default queue of that cluster is dropped

[ntascii]

Describe the bug
When changing a description of a cluster's default queue, the cluster will no longer have its assigned default queue.
We have a cluster managed in terraform. The usage can be simplified like:

resource "buildkite_cluster_queue" "test_queue" {
  key         = "test_queue"
  description = "test description"
  cluster_id  = module.test_cluster.cluster_id
}

resource "buildkite_cluster_default_queue" "default" {
  cluster_id = module.test_cluster.cluster_id
  queue_id   = buildkite_cluster_queue.test_queue
}

To Reproduce
Steps to reproduce the behavior:

• Change description of the default queue
• terraform apply
• The description is updated, the state file still contains resource buildkite_cluster_default_queue however, there is no longer a default queue for the cluster
• Hit error No default queue is assigned to the cluster whenever doing a terraform plan afterwards.

Expected behavior
Default queue should not be dropped when changing it's description.

Additional context
Add any other context about the problem here.

[tomowatt]

Hey @ntascii

We've found that there is an issue with the GraphQL API itself that results Default Queue being removed when the Queue is updated until this is fixed we recommend adding the replace_triggered_by lifecycle onto the buildkite_cluster_default_queue resources e.g.,

resource "buildkite_cluster" "local" {
  name        = "TF cluster"
  description = "Cluster for TF projects"
}

resource "buildkite_cluster_queue" "test_queue" {
  cluster_id  = buildkite_cluster.local.id
  key         = "test_queue"
  dispatch_paused = "true"
}

resource "buildkite_cluster_default_queue" "test_default_queue" {
  cluster_id = buildkite_cluster.local.id
  queue_id   = buildkite_cluster_queue.test_queue.id

  lifecycle {
    replace_triggered_by = [  buildkite_cluster_queue.test_queue ]
  }
}

the PR linked above includes other fixes for Cluster Queues but we've raised it to the Product Team to correct the GraphQL API so the workaround is not required.