Issue Summary

After a successful terraform apply with no configuration changes, immediately running terraform plan on resources managed by the atlassian-operations Terraform provider (v2.0.5) produces a perpetual in-place update diff for several Computed attributes on atlassian-operations_api_integration (type Prometheus) and atlassian-operations_integration_action (action types acknowledge, close, and cloudwatch_close). The plan never converges - applying and planning repeatedly produces the identical diff every time.

The affected attributes are:

•  atlassian-operations_api_integration: advanced, api_key, directions, domains, maintenance_sources, and isDefaultIntegration inside type_specific_properties
•  atlassian-operations_integration_action: filter, action_mapping, and type_specific_properties

None of these attributes are set in the user's Terraform configuration. The api_integration attributes are Read-Only and cannot be set in config at all. The integration_action attributes are Optional but intentionally left unset.

Root cause: When the provider's Read function refreshes state by calling the Atlassian API, the GET response omits fields that are at their server-side default values. The provider writes the API response directly to state without preserving prior state values for fields the API did not return. This blanks out those attributes in state. On the next plan, Terraform detects the previously-known values are now missing and marks them as (known after apply), triggering a perpetual update cycle.
The fix requires the provider's Read function to preserve the prior state value for any Computed attribute when the API response does not return a value for that field, rather than overwriting state with null or zero.
This is the same class of bug as JSDCLOUD-17006 (fixed in v1.1.4) and JSDCLOUD-18242 (fixed 2026-03-16).

Steps to Reproduce

1. Define an atlassian-operations_api_integration resource of type Prometheus and one or more atlassian-operations_integration_action resources of type acknowledge, close, or cloudwatch_close, leaving advanced, api_key, directions, domains, maintenance_sources, type_specific_properties.isDefaultIntegration, and filter unset in config. Run terraform apply and confirm it completes successfully.
2. Immediately run terraform plan again with no changes to configuration, provider version, or the Atlassian environment. Observe that the plan reports in-place updates to all of the attributes listed above. Run terraform apply followed by terraform plan again — the identical diff reappears.

Expected Results

After a successful terraform apply with no configuration or environment changes, terraform plan should report no changes. Computed attributes whose values have not changed on the Atlassian side should be preserved in state from the previous apply and should not appear in the plan diff.

Actual Results

terraform plan shows the following perpetual diff on every run:
On atlassian-operations_api_integration:

~ advanced            = true -> (known after apply)
+ api_key             = (sensitive value)
~ directions          = ["incoming"] -> (known after apply)
~ domains             = ["alert"] -> (known after apply)
~ maintenance_sources = [] -> (known after apply)
~ type_specific_properties = jsonencode(

{     + isDefaultIntegration = false       # (5 unchanged attributes hidden)   }

)
On atlassian-operations_integration_action (acknowledge and close):

~ filter =

{     ~ condition_match_type = "match-all" -> (known after apply)     ~ conditions           = [] -> (known after apply)     ~ conditions_empty     = false -> (known after apply)   }

-> (known after apply)
~ type_specific_properties = jsonencode({}) -> (known after apply)

Workaround

Add lifecycle { ignore_changes } blocks to the affected resources inside the module source. See the customer-facing workaround for the full configuration. Note that ignore_changes on type_specific_properties suppresses drift detection for the entire block, not just the affected field, so this should be removed once a provider fix ships.