Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error "409 Conflict" when updating a Sentinel analytics rule #25564

Open
1 task done
xiangyx opened this issue Apr 10, 2024 · 2 comments · May be fixed by #25688
Open
1 task done

Error "409 Conflict" when updating a Sentinel analytics rule #25564

xiangyx opened this issue Apr 10, 2024 · 2 comments · May be fixed by #25688

Comments

@xiangyx
Copy link

xiangyx commented Apr 10, 2024

Is there an existing issue for this?

  • I have searched the existing issues

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 "me too" comments, 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 and review the contribution guide to help.

Terraform Version

1.3.9

AzureRM Provider Version

3.98.0

Affected Resource(s)/Data Source(s)

azurerm_sentinel_alert_rule_scheduled

Terraform Configuration Files

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "example" {
  name     = "example"
  location = "West Europe"
}

resource "azurerm_log_analytics_workspace" "example" {
  name                = "example"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  sku                 = "PerGB2018"
}

resource "azurerm_sentinel_log_analytics_workspace_onboarding" "example" {
  workspace_id = azurerm_log_analytics_workspace.example.id
}

resource "azurerm_sentinel_alert_rule_scheduled" "example" {
  name                       = "example"
  log_analytics_workspace_id = azurerm_sentinel_log_analytics_workspace_onboarding.example.workspace_id
  alert_rule_template_guid = "173f8699-6af5-484a-8b06-8c47ba89b380"
  alert_rule_template_version = "1.0.4"
  display_name               = "example"
  severity                   = "Medium"
  query                      = <<QUERY
AzureActivity |
  where OperationName == "Create or Update Virtual Machine" or OperationName =="Create Deployment" |
  where ActivityStatus == "Succeeded" |
  make-series dcount(ResourceId) default=0 on EventSubmissionTimestamp in range(ago(7d), now(), 1d) by Caller
QUERY
}

Debug Output/Panic Output

╷
│ Error: creating Sentinel Alert Rule Scheduled "Alert Rule (Subscription: \"25d04c6b-xxxxxx\"\nResource Group Name: \"example\"\nWorkspace Name: \"example\"\nRule: \"example\")": unexpected status 409 (409 Conflict) with error: Conflict: The rule with id 'example' was recently deleted. You need to allow some time before re-using the same id. Please try again later.
│
│   with azurerm_sentinel_alert_rule_scheduled.example,
│   on main.tf line 21, in resource "azurerm_sentinel_alert_rule_scheduled" "example":
│   21: resource "azurerm_sentinel_alert_rule_scheduled" "example" {
│
╵

Expected Behaviour

The alert_rule_template_version is updated, e.g., from "1.0.4" to "1.0.5", and the deployment is successful in one attempt.

Actual Behaviour

The deployment failed with error code 409, output with a message saying it needs some time before re-using the same id.

Essentially, according to the docs, changing the version of the alert rule will force a new Sentinel Scheduled Alert Rule to be created. Previously, creating a newly updated rule will be done immediately after destroying the resources.

Still, now it seems that the time of this process is dramatically extended and will require another apply attempt after almost one hour, which in the meantime introduces the risk of missing the rule that was going to be updated.

Steps to Reproduce

  1. deploy the resource with alert_rule_template_version being "1.0.4"
  2. update alert_rule_template_version being` to "1.0.5" and deploy it again

Important Factoids

none

References

No response

@ziyeqf
Copy link
Contributor

ziyeqf commented Apr 22, 2024

Hi @xiangyx, thanks for reporting.

The 429 error is returned by the Azure backend service. On the provider side we can almost do nothing about it but to obey the service's implementation.
However, we found upgrading the alert_rule_template_version could be done without forcing a new azurerm_sentinel_alert_rule_scheduled to be re-created. I have submitted a PR(#25688) for this. You can subscribe it to keep track on it.

Thanks.

@xiangyx
Copy link
Author

xiangyx commented Apr 22, 2024

Hi @ziyeqf, thanks for investigating and making the changes, it's awesome.

Can't wait for the next patch to fix the bug!

@rcskosir rcskosir added the bug label Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants