Is there an existing issue for this?
Provider Version
v1.30.0
Terraform Version
pulumi-mongodbatlas 4.13.0, which vendors provider v1.30.0
Terraform Edition
Terraform Open Source (OSS)
Current Behavior
This is the Delete-side counterpart of #3069, which fixed Read() for users that have already been deleted on Atlas's side but remain present in Terraform state. Delete() hard-fails in that same situation.
When state records a mongodbatlas_database_user that no longer exists in Atlas (e.g., vanishing after a CI deployment was stopped halfway through), the next destroy or replace calls the delete API, receives 404 USER_NOT_FOUND, and the provider aborts the entire run. Since the purpose of a delete is to ensure the user does not exist, a 404 in this path indicates that the desired outcome has been reached rather than a failure that should stop the apply.
Delete() currently discards the HTTP response, so a 404 is indistinguishable from any other error:
// internal/service/databaseuser/resource_database_user.go
_, err := connV2.DatabaseUsersAPI.DeleteDatabaseUser(
ctx,
state.ProjectID.ValueString(),
state.AuthDatabaseName.ValueString(),
state.Username.ValueString()).Execute()
if err != nil {
resp.Diagnostics.AddError("error when destroying the database user resource", err.Error())
return
}
Capturing the response and treating validate.StatusNotFound as a successful delete, as teamprojectassignment does in its Delete, would address this.
I believe this aligns with HashiCorp's framework guidance and the behavior several sibling resources already implement in Delete (e.g., teamprojectassignment and projectipaccesslist).
Terraform configuration to reproduce the issue
resource "mongodbatlas_database_user" "oidc_user" {
project_id = var.project_id
username = "${var.tenant_id}/my-workload-identity"
auth_database_name = "$external"
oidc_auth_type = "USER"
roles {
role_name = "readWrite"
database_name = var.database_name
}
}
Steps To Reproduce
- Apply the config above so the user exists in both Atlas and Terraform state.
- Delete the user directly in the Atlas UI (or interrupt an apply after it deleted the user but before it saved state).
- Run terraform destroy, or any apply that plans a delete/replace of that user, without refreshing first.
- The run fails immediately with USER_NOT_FOUND instead of completing.
Logs
Code of Conduct
Is there an existing issue for this?
Provider Version
v1.30.0
Terraform Version
pulumi-mongodbatlas 4.13.0, which vendors provider v1.30.0
Terraform Edition
Terraform Open Source (OSS)
Current Behavior
This is the Delete-side counterpart of #3069, which fixed
Read()for users that have already been deleted on Atlas's side but remain present in Terraform state.Delete()hard-fails in that same situation.When state records a
mongodbatlas_database_userthat no longer exists in Atlas (e.g., vanishing after a CI deployment was stopped halfway through), the next destroy or replace calls the delete API, receives404 USER_NOT_FOUND, and the provider aborts the entire run. Since the purpose of a delete is to ensure the user does not exist, a 404 in this path indicates that the desired outcome has been reached rather than a failure that should stop the apply.Delete()currently discards the HTTP response, so a 404 is indistinguishable from any other error:Capturing the response and treating
validate.StatusNotFoundas a successful delete, asteamprojectassignmentdoes in itsDelete, would address this.I believe this aligns with HashiCorp's framework guidance and the behavior several sibling resources already implement in
Delete(e.g.,teamprojectassignmentandprojectipaccesslist).Terraform configuration to reproduce the issue
Steps To Reproduce
Logs
Code of Conduct