signalsciences / terraform-provider-sigsci

Signal sciences terraform provider
MIT License
26 stars 30 forks source link

With provider update, the sigsci_site_rule got recreated #192

Closed chenrui333 closed 7 months ago

chenrui333 commented 1 year ago

👋 not sure if anyone else is experiencing this, but I did observe some weird issue when updating the sigsci provider version from 1.2.27 to 1.2.30, and seeing sigsci_site_rule recreation in the terraform plan

shawnps commented 1 year ago

Hi @chenrui333, thanks for raising this issue.

We think this was because the site rule actions.type had ForceNew: true, and then between version 1.2.27 and 1.2.30 we removed the default response_code inside of actions.

Since actions is a TypeSet, any change to it generates new state. Since response_code no longer set a default, the actions state changed, causing a forced replacement.

We removed ForceNew from actions.type and added it to the top-level site rule type attribute. This is because changing a rule type in the UI from request to rate limit for example isn't allowed and thus should trigger a forced replacement if changed in the TF.

The change is here and included in v2.1.1.

cc @Integralist @daniel-corbett

chenrui333 commented 1 year ago

We think this was because the site rule actions.type had ForceNew: true, and then between version 1.2.27 and 1.2.30 we removed the default response_code inside of actions.

yeah, I think the default response_code removal is an issue, that seems like another breaking change (can I ask why did you remove the default response_code?) Thanks!

chenrui333 commented 1 year ago

Now understanding the response_code needs to be specified, I also noticed this

      - actions {
          - response_code = 0 -> null
          - type          = "block" -> null
        }
      + actions {
          + response_code = 406
          + type          = "block"
        }

@shawnps Should I be concerned about response_code = 0

daniel-corbett commented 7 months ago

@chenrui333 - I missed this thread - to answer your question

can I ask why did you remove the default response_code?

The answer is in the related PR (#186)

response_code is only valid for for the block action. By setting a default it forces it to be set for all action types including those that it is not valid for. When response_code is empty on a blocking action the API just defaults to using the site default (e.g. 406).

This commit removes the default from the Terraform provider for response_code and also updates the documentation to indicate that it is only valid for the block action type.

To answer your other question

Should I be concerned about response_code = 0

I believe that was fixed in #187