Description
🐛 What happened?
When changing a property of a resource that forces replacement instead of changing the resource, terraform apply
does not execute successfully.
The following error is returned: Could not create resource: Requested 'ResourceName' is already in use
.
There is then a 5 minute delay before the resource can be created again and all terraform apply
executions within that time limit also fail.
This was encountered when changing the enable_schemas
configuration option of the fabric_lakehouse
resource.
🔬 How to reproduce?
- Create a Lakehouse in a workspace with configuration option
enable_schemas
set totrue
and then runterraform apply
. - Once this is deployed, changed the
enable_schemas
option tofalse
and then runterraform apply
again - The following error is returned
Could not create resource: Requested 'LakehouseName' is already in use
- The Lakehouse will not be able to be created for the next 5 minutes
- Once 5 minutes has passed the Lakehouse can be created again
🏗️ Code Sample / Log
Lakehouse resource:
resource "fabric_lakehouse" "terraform_lakehouse" { display_name = "terraformLH" workspace_id = fabric_workspace.terraform_workspace.id configuration = { enable_schemas = true } }
The enable_schemas configuration property is changed from true to false
Terraform Apply Output
The output of the terraform apply
command before approval
fabric_lakehouse.terraform_lakehouse must be replaced
-/+ resource "fabric_lakehouse" "terraform_lakehouse" {
~ configuration = { # forces replacement
~ enable_schemas = false -> true # forces replacement
}
~ id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" -> (known after apply)
~ properties = {
+ default_schema = (known after apply)
~ onelake_files_path = "https://onelake.dfs.fabric.microsoft.com/xxxxxxxxxxxxxxxx/xxxxxxxxxxxxxxx/Files" -> (known after apply)
~ onelake_tables_path = "https://onelake.dfs.fabric.microsoft.com/xxxxxxxxxxxxxxxxxxxxxxx/Tables" -> (known after apply)
~ sql_endpoint_properties = {
~ connection_string = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.datawarehouse.fabric.microsoft.com" -> (known after apply)
~ id = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" -> (known after apply)
~ provisioning_status = "Success" -> (known after apply)
} -> (known after apply)
} -> (known after apply)
# (3 unchanged attributes hidden)
}Plan: 1 to add, 0 to change, 1 to destroy.
Error:
│ Error: create operation │ │ with fabric_lakehouse.terraform_lakehouse, │ on lakehouse.tf line 1, in resource "fabric_lakehouse" "terraform_lakehouse": │ 1: resource "fabric_lakehouse" "terraform_lakehouse" { │ │ Could not create resource: Requested 'terraformLH' is already in use
📷 Screenshots
No response
📈 Expected behavior
The resource can be deleted and then created in the same execution without error and without a time delay .
🌌 Environment (Provider Version)
0.1.0-beta.5
🌌 Environment (Terraform Version)
1.10.0
🌌 Environment (OS)
Linux
📎 Additional context
No response
🔰 Code of Conduct
- I agree to follow this project's Code of Conduct.
Activity
DariuszPorowski commentedon Dec 6, 2024
Hi @andrewbrine Actually this is not a provider bug, but standard Fabric behavior itself. We don't have much room to maneuver to do anything on the Provider side. The workaround is only to wait and then create the item once again.
PTAL @Halamish51 @cisraeli @badeamarjieh and see if this is a bug in the Fabric API side.
Lachlan-White commentedon Jan 3, 2025
@andrewbrine for our own safety and protection! Wish we would follow the same behaviours across Microsoft APIs so the experience for those working on multiple via Terraform is the same.
Halamish51 commentedon May 18, 2025
We are actively working on problem solution.