azurerm_linux_web_app_slot - fix ignored worker_count argument in site_config block

[dkanbier]

Currently the worker_count argument in the site_config block on azurerm_linux_web_app_slot seems to get ignored when the resource is created:

resource "azurerm_linux_web_app_slot" "example" {
  name           = "example-slot"
  app_service_id = azurerm_linux_web_app.example.id

  site_config {
    worker_count = 2
  }
}

Running terraform apply on this code will show no issues and finish successfully. The resulting slot will have a worker_count of 1 however, which you can check via the JSON View of the slot in the Azure Portal.

Re-running a terraform plan directly after the terraform apply will show differences:

      ~ site_config {
          ~ worker_count                            = 1 -> 2

While debugging I discovered the NumberOfWorkers argument is simply missing from the AzureRM API call to Azure when the azurerm_linux_web_app_slot resource gets created.

I think this is because it is never added to the expanded arguments.

The goal of this PR is to remedy this, by adding the NumberOfWorkers to the expanded arguments. This causes the resulting slot to have the correct number of workers.

Unit tests:

=== RUN   TestAccLinuxWebAppSlot_complete
=== PAUSE TestAccLinuxWebAppSlot_complete
=== RUN   TestAccLinuxWebAppSlot_completeUpdate
=== PAUSE TestAccLinuxWebAppSlot_completeUpdate
=== CONT  TestAccLinuxWebAppSlot_complete
=== CONT  TestAccLinuxWebAppSlot_completeUpdate
--- PASS: TestAccLinuxWebAppSlot_complete (152.51s)
--- PASS: TestAccLinuxWebAppSlot_completeUpdate (221.91s)
PASS

fixes #24678

[dkanbier]

Added issue #24678 with detailed debug logs and steps to reproduce the issue.

[sven5]

When will this one be merged?

[jackofallops]

Hi @dkanbier - Thanks for this PR, and for the catch on the missing property. Due to a recent change in the SDK, this property is now an int64 type, so no longer requires casting. If you can update, we can get the tests run and hopefully get this merged when they pass.

Thanks!

[dkanbier]

Hi @dkanbier - Thanks for this PR, and for the catch on the missing property. Due to a recent change in the SDK, this property is now an int64 type, so no longer requires casting. If you can update, we can get the tests run and hopefully get this merged when they pass.

Thanks!

Hi @jackofallops , I've applied your suggested changes and tried rebuilding the module but it fails:

internal/services/appservice/helpers/web_app_slot_schema.go:670:30: cannot use pointer.To(s.WorkerCount) (value of type *int) as *int32 value in assignment
internal/services/appservice/helpers/web_app_slot_schema.go:823:30: cannot use pointer.To(s.WorkerCount) (value of type *int) as *int32 value in assignment

I think we would have to change the type of NumberOfWorkers.

If we do that I think we also need to update a lot more code to remove the int32 casting which is currently used on WorkerCount throughout the code.

Please let me know if you want to pursue this or not so I can make changes accordingly. If we do the PR will become quite a bit bigger in my mind.

[jackofallops]

Hi @dkanbier - Thanks for this PR, and for the catch on the missing property. Due to a recent change in the SDK, this property is now an int64 type, so no longer requires casting. If you can update, we can get the tests run and hopefully get this merged when they pass.
Thanks!

Hi @jackofallops , I've applied your suggested changes and tried rebuilding the module but it fails:

internal/services/appservice/helpers/web_app_slot_schema.go:670:30: cannot use pointer.To(s.WorkerCount) (value of type *int) as *int32 value in assignment
internal/services/appservice/helpers/web_app_slot_schema.go:823:30: cannot use pointer.To(s.WorkerCount) (value of type *int) as *int32 value in assignment

I think we would have to change the type of NumberOfWorkers.

If we do that I think we also need to update a lot more code to remove the int32 casting which is currently used on WorkerCount throughout the code.

Please let me know if you want to pursue this or not so I can make changes accordingly. If we do the PR will become quite a bit bigger in my mind.

Hi @dkanbier - To pick up the change in main to build successfully you'd need to update your fork's main branch and rebase your PR branch on top of that. (you should then end up with: https://github.com/hashicorp/terraform-provider-azurerm/blob/main/internal/services/appservice/helpers/web_app_slot_schema.go#L46) in your local.) It's not absolutely necessary for the PR however, since the merge branch appears to be handling it just fine. Now you've made the change, I can run workflows and the testing on our CI server for this.

[dkanbier]

Hi @dkanbier - Thanks for this PR, and for the catch on the missing property. Due to a recent change in the SDK, this property is now an int64 type, so no longer requires casting. If you can update, we can get the tests run and hopefully get this merged when they pass.
Thanks!

Hi @jackofallops , I've applied your suggested changes and tried rebuilding the module but it fails:

internal/services/appservice/helpers/web_app_slot_schema.go:670:30: cannot use pointer.To(s.WorkerCount) (value of type *int) as *int32 value in assignment
internal/services/appservice/helpers/web_app_slot_schema.go:823:30: cannot use pointer.To(s.WorkerCount) (value of type *int) as *int32 value in assignment

I think we would have to change the type of NumberOfWorkers.
If we do that I think we also need to update a lot more code to remove the int32 casting which is currently used on WorkerCount throughout the code.
Please let me know if you want to pursue this or not so I can make changes accordingly. If we do the PR will become quite a bit bigger in my mind.

Hi @dkanbier - To pick up the change in main to build successfully you'd need to update your fork's main branch and rebase your PR branch on top of that. (you should then end up with: https://github.com/hashicorp/terraform-provider-azurerm/blob/main/internal/services/appservice/helpers/web_app_slot_schema.go#L46) in your local.) It's not absolutely necessary for the PR however, since the merge branch appears to be handling it just fine. Now you've made the change, I can run workflows and the testing on our CI server for this.

@jackofallops Ah yes you are right, I did the rebase but forgot I was on my fork. Sorry!

[jackofallops]

@jackofallops Ah yes you are right, I did the rebase but forgot I was on my fork. Sorry!

No harm done, tests are running now, one of the team will get this merged assuming everything is ✅

Thanks again for the contribution!

[dkanbier]

Hi @jackofallops , any news on the tests maybe?

[mbfrahry]

LGTM! Thanks for this @dkanbier

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.