azuread_service_principal for resource and data resource needs to be updated to support "client_id"

[scott-doyland-burrows]

Extension Version

v2.28.2

VS Code Version

Version: 1.82.2 (user setup) Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d Date: 2023-09-14T05:55:25.390Z Electron: 25.8.1 ElectronBuildId: 23779380 Chromium: 114.0.5735.289 Node.js: 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.19044

Operating System

Windows 10 using WSL

Terraform Version

Terraform v1.6.3 on linux_amd64 + provider registry.terraform.io/hashicorp/azuread v2.45.0 + provider registry.terraform.io/hashicorp/azurerm v3.79.0

Steps to Reproduce

data "azuread_service_principal" "test1" {
  client_id = "redacted"
}

resource "azuread_service_principal" "test2" {
  client_id = "redacted"
}

Expected Behavior

client_id should be accepted. It used to be application_id but this is deprecated.

Actual Behavior

Terraform Configuration

terraform {
  cloud {
  }
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "3.79.0"
    }
    azuread = {
      source  = "hashicorp/azuread"
      version = "2.45.0"
    }
  }
}

data "azuread_service_principal" "test1" {
  client_id = "redacted"
}

resource "azuread_service_principal" "test2" {
  client_id = "redacted"
}

Project Structure

N/A

Gist

No response

Anything Else?

No response

Workarounds

No response

References

No response

Help Wanted

• [ ] I'm interested in contributing a fix myself

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[radeksimko]

Thanks for the report. I was able to reproduce it.

It looks like there is some inconsistency in how/when we load the correct provider schema (version). The first time we produce diagnostics the old (incorrect) schema is used and upon typing, the new (correct) schema is then available and used.

https://github.com/hashicorp/vscode-terraform/assets/287584/4fdf0523-07b7-4740-b9a2-aeb7abeee235

[dbanck]

FYI, the latest release 2.29.0 contains an updated schema for the azuread provider and partially fixes the reported problem. The update should show up in VS Code automatically.

The problem that Radek describes about running a validation before retrieving the provider schema via Terraform CLI still exists. So I'd keep this issue open.

[AndersRunningen]

Experience the same for the azuread resource azuread_application_federated_identity_credential. Linting gives the wrong correction for application_id in for example

resource "azuread_application_federated_identity_credential" "github-dns" {
  for_each = var.repository

  application_id = azuread_application.github[each.key].id
  display_name   = "${each.value.dns}-${var.general.environment_name}"
  description    = "Deployments for ${each.value.dns} in ${var.general.environment_name}"
  audiences      = ["api://AzureADTokenExchange"]
  issuer         = "https://token.actions.githubusercontent.com"
  subject        = "repo:SparebankenVest/${each.value.dns}:environment:${var.general.environment_name}"
}

where we get Required attribute "application_object_id" not specified: An attribute named "application_object_id" is required here that is not true based on the documentation to the latest Azure AD provider

You might already know this, but thought I could ad it. When testing the prerelease of the plugin it all went away 👍 So it seems like you have done something correct here 🥇