dataprotection - downgrade API version to 2025-07-01

[sreallymatt]

Community Note

• Please vote on this PR by adding a 👍 reaction to the original PR to help the community and maintainers prioritize for review
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for PR followers and do not help prioritize for review

Description

While tests were passing at the time of the version bump, it appears the API @ version 2025-09-01 has introduced a new check, that's causing a 406 (which is really a 400, more on that below).

2025-09-01 no longer allows soft_delete with a value other than AlwaysOn, thus the downgrade to 2025-07-01 as this version does not appear to have this problem.

Error message for reference:

{
  "error": {
    "additionalInfo": [
      {
        "type": "UserFacingError",
        "info": {
          "message": "This API version requires backup vaults to have the soft delete setting configured to Enable Always-On Soft Delete.",
          "recommendedAction": [
            "To use this API version, you must configure backup vaults with the soft delete setting set to Enable Always-On Soft Delete. If you don't want to enable this setting, use an older API version instead."
          ],
          "details": null,
          "code": "DppAlwaysOnSoftDeleteStateMandatory",
          "target": "",
          "innerError": null,
          "isRetryable": false,
          "isUserError": false
        }
      }
    ],
    "code": "DppAlwaysOnSoftDeleteStateMandatory",
    "message": "This API version requires backup vaults to have the soft delete setting configured to Enable Always-On Soft Delete.",
    "target": null,
    "details": null
  }
}

What this doesn't fix is the 406 responses on errors, this appears to be present in all API versions (tested all the way back to 2023-01-01). When the Accept header includes a charset parameter, and the API request is invalid for some reason, the API responds with a 406 rather than a 400. The SDK used by the provider includes an Accept header with the value of application/json; charset=utf-8; IEEE754Compatible=false which has been present in the SDK since 2022, and in the provider since early 2023.

PR Checklist

• I have followed the guidelines in our Contributing Documentation.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have checked if my changes close any open issues. If so please include appropriate closing keywords below.
• I have updated/added Documentation as required written in a helpful and kind way to assist users that may be unfamiliar with the resource / data source.
• I have used a meaningful PR title to help maintainers and other users understand this change and help prevent duplicate work.
  For example: “resource_name_here - description of change e.g. adding property new_property_name_here”

Changes to existing Resource / Data Source

• I have added an explanation of what my changes do and why I'd like you to include them (This may be covered by linking to an issue above, but may benefit from additional explanation).
• I have written new tests for my resource or datasource changes & updated any relevant documentation.
• I have successfully run tests with my changes locally. If not, please provide details on testing challenges that prevented you running the tests.
• (For changes that include a state migration only). I have manually tested the migration path between relevant versions of the provider.

Testing

• My submission includes Test coverage as described in the Contribution Guide and the tests pass. (if this is not possible for any reason, please include details of why you did or could not add test coverage)

RecoveryServices

DataProtection

Change Log

Below please provide what should go into the changelog (if anything) conforming to the Changelog Format documented here.

• azurerm_resource - support for the thing1 property [GH-00000]

This is a (please select all that apply):

• Bug Fix
• New Feature (ie adding a service, resource, or data source)
• Enhancement
• Breaking Change

Related Issue(s)

Fixes #31874

AI Assistance Disclosure

• AI Assisted - This contribution was made by, or with the assistance of, AI/LLMs

Rollback Plan

If a change needs to be reverted, we will publish an updated version of the provider.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

Note

If this PR changes meaningfully during the course of review please update the title and description as required.

[QixiaLu]

Hi @sreallymatt , thanks for working on this! This is caused by the Secure by Default feature. Downgrade to 2025-07-01 could help address it for now.

In Backup vault, for API version 2025-09-01 or later, for regions Australia East, West Central US and East Asia, users can only set AlwaysOn for the soft_delete property. They will come across the above issue if On or Off is sent to the API. For other regions, it's remained unchanged. This explains why acctests in the previous PR passed and some in main are also successful.

[sreallymatt]

Hi @QixiaLu - There do seem to be more than those 3 regions that prevent settings other than AlwaysOn, I didn't try all, but West Europe is an example of one that also fails, Canada Central works.

Terraform will perform the following actions:

  # azurerm_data_protection_backup_vault.test will be created
  + resource "azurerm_data_protection_backup_vault" "test" {
      + datastore_type             = "VaultStore"
      + id                         = (known after apply)
      + immutability               = "Disabled"
      + location                   = "westeurope"
      + name                       = "acctest-bv-0303"
      + redundancy                 = "LocallyRedundant"
      + resource_group_name        = "dev"
      + retention_duration_in_days = 14
      + soft_delete                = "On"
    }

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

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

azurerm_data_protection_backup_vault.test: Creating...
╷
│ Error: creating DataProtection BackupVault ("Backup Vault (Subscription: \"{subscriptionID}\"\nResource Group Name: \"dev\"\nBackup Vault Name: \"acctest-bv-0303\")"): performing BackupVaultsCreateOrUpdate: unexpected status 406 (406 Not Acceptable) received with no body
│
│   with azurerm_data_protection_backup_vault.test,
│   on main.tf line 44, in resource "azurerm_data_protection_backup_vault" "test":
│   44: resource "azurerm_data_protection_backup_vault" "test" {
│

Terraform is showing a 406 here, due to a hardcoded accept header that the service doesn't seem to handle, removing that and manually sending the request returns the (un?)expected 400 (This API version requires backup vaults to have the soft delete setting configured to Enable Always-On Soft Delete.)

[QixiaLu]

Hi @sreallymatt , I have tested it in portal, seems like more regions are in Preview other than those documented in the learn site. The underlying 400 is expected as the secure by default feature only allows AlwaysOn value. I'll reach out to the service team about the unexpected 406 and regions in Preview.

[mstroob]

LGTM