You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hit state error due to an API key having expired.
While applying a change to update the hosts list of an existing private application (adding a new host entry), when the apply failed due to the 403 permissions error the state was still updated to reflect as if the change had gone ahead.
Confirmed within the portal that the change had not gone ahead, and so had to manually add the values to fix the state mismatch.
Redacted example:
# Plan output
Terraform will perform the following actions:
# module.netskope_privateapps["example_private_app"].netskope_privateapps.privateapp will be updated in-place
~ resource "netskope_privateapps" "privateapp" {
~ host = "existing.host1, existing.host2, new.host1"
id = "1112"
# (4 unchanged attributes hidden)
# (5 unchanged blocks hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
# Apply output
module.netskope_privateapps["example_private_app"].netskope_privateapps.privateapp: Modifying... [id=1112]
╷
│ Error: unknown error, status code: 403
│
│ with module.netskope_privateapps["example_private_app"].netskope_privateapps.privateapp,
│ on privateapp-module\main.tf line 24, in resource "netskope_privateapps" "privateapp":
│ 24: resource "netskope_privateapps" "privateapp" {
│
╵
# Follow up plan suggesting no changes necessary, even though the change was never applied
PS C:\git\NetSkope>terraform plan
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
Expected behaviour would be for the state to not be updated when an apply fails due to a 403 permissions error for an expired API token
The text was updated successfully, but these errors were encountered:
Hit state error due to an API key having expired.
While applying a change to update the hosts list of an existing private application (adding a new host entry), when the apply failed due to the 403 permissions error the state was still updated to reflect as if the change had gone ahead.
Confirmed within the portal that the change had not gone ahead, and so had to manually add the values to fix the state mismatch.
Redacted example:
Expected behaviour would be for the state to not be updated when an apply fails due to a 403 permissions error for an expired API token
The text was updated successfully, but these errors were encountered: