[Bug]: Additional backup copies should be disabled if copy_settings are not provided

[Frank-Reichenbach]

Is there an existing issue for this?

• I have searched the existing issues

Provider Version

v1.15.3 and v1.17.3

Terraform Version

v1.9.0

Terraform Edition

Terraform Open Source (OSS)

Current Behavior

When I change my resource configuration for the mongodbatlas_cloud_backup_schedule resource, I expected, that when I omit the copy_settings section, it would turn off the ADDITIONAL BACKUP COPIES for my backup policies, but it didn't.

I have 2 different backup policies, one "advanced" which provides the copy_settings section to create additional copies of the backup snapshots, and another one which doesn`t. After creating a mongodbatlas_cloud_backup_schedule with the copy_settings provided, it turns on the ADDITIONAL BACKUP COPIES correctly. But switching back to my basic backup policies, without the copy_settings, it did not turn off the ADDITIONAL BACKUP COPIES, as I expected.

Terraform configuration to reproduce the issue

terraform {
  required_version = ">= 1.8.5, < 2.0.0"
  required_providers {
    mongodbatlas = {
      "source" = "mongodb/mongodbatlas"
      version  = "~> 1.15.3" # I tested with versions v1.15.3 and v1.17.3
    }
  }
}

provider "mongodbatlas" {
  private_key = local.mongodb_private_key
  public_key  = local.mongodb_public_key
}

locals {
  # please provide valid config
  my_mongodb_project_id = ""
  mongodb_private_key = ""
  mongodb_public_key = ""

  # this flag should turn off ADDITIONAL BACKUP COPIES when set to false
  advanced_backup_enabled = true
  advanced_backup = local.advanced_backup_enabled ? { enabled = true } : {}
}

resource "mongodbatlas_advanced_cluster" "main" {
  project_id             = local.my_mongodb_project_id
  name                   = "test"
  cluster_type           = "REPLICASET"
  mongo_db_major_version = "7"
  pit_enabled            = local.advanced_backup_enabled
  backup_enabled         = true
  replication_specs {
    region_configs {
      electable_specs {
        instance_size = "M10"
        node_count    = 3
      }
      provider_name = "AZURE"
      priority      = 7
      region_name   = "GERMANY_WEST_CENTRAL"
    }
  }
}

resource "mongodbatlas_cloud_backup_schedule" "backup" {
  project_id   = local.my_mongodb_project_id
  cluster_name = mongodbatlas_advanced_cluster.main.name

  dynamic "policy_item_hourly" {
    for_each = local.advanced_backup
    content {
      frequency_interval = 1
      retention_unit     = "days"
      retention_value    = 3
    }
  }

  policy_item_daily {
    frequency_interval = 1
    retention_unit     = "days"
    retention_value    = 7
  }

  dynamic "copy_settings" {
    for_each = local.advanced_backup
    content {
      cloud_provider = "AZURE"
      frequencies = [
        "DAILY"
      ]
      region_name         = "EUROPE_WEST"
      replication_spec_id = mongodbatlas_advanced_cluster.main.replication_specs.*.id[0]
      should_copy_oplogs  = true
    }
  }
}

Steps To Reproduce

1. apply the config above with: local.advanced_backup_enabled=true
2. check the ADDITIONAL BACKUP COPIES for the backup policy, this is turned on (as expected)
3. apply the config above with: local.advanced_backup_enabled=false
4. ADDITIONAL BACKUP COPIES should be turned off, but the setting is not applied to the backup policy, although tf apply finished without errors

Logs

No errors, apply works, but does not change the setting in mongodb atlas.

Code of Conduct

• I agree to follow this project's Code of Conduct

[github-actions]

Thanks for opening this issue! Please make sure you've followed our guidelines when opening the issue. In short, to help us reproduce the issue we need:

• Terraform configuration file used to reproduce the issue
• Terraform log files from the run where the issue occurred
• Terraform Atlas provider version used to reproduce the issue
• Terraform version used to reproduce the issue
• Confirmation if Terraform OSS, Terraform Cloud, or Terraform Enterprise deployment

The ticket CLOUDP-259859 was created for internal tracking.

[Frank-Reichenbach]

Wow, thats not even 24h after I created the issue.
Thank you for the prompt resolution of the issue, can't wait to see the new release!

[EspenAlbert]

@Frank-Reichenbach thank you for opening this issue and the clear reproduction details!
The fix should be part of the next release 👍

[Frank-Reichenbach]

Wir haben auf das neue Release v1.17.4 aktualisiert und getestet, funktioniert wie erwartet 👍