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.
- If an issue is assigned to a user, that user is claiming responsibility for the issue.
- OKTA support Customers can ask to reach out to Okta Developer Support Engineer/Customer Success Engineer to expedite investigation and resolution of this issue.
Description
okta_push_group discards the diagnostic fields the API already returns, which
makes a Terraform-managed mapping strictly less observable than the same mapping
viewed in the Admin Console.
GET /api/v1/apps/{appId}/group-push/mappings/{mappingId} returns
errorSummary, lastPush, created and lastUpdated. The Go SDK models all
four on GroupPushMapping with full accessors (GetErrorSummary,
GetLastPush, GetCreated, GetLastUpdated), in the very same struct the
provider already reads status and targetGroupId from.
mapPushGroupResourceToState writes only id, source_group_id,
target_group_id, status and app_config. The schema has no attribute for
any of the four, and errorSummary/lastPush do not appear anywhere in
resource_okta_push_group.go. So the data is fetched and dropped.
Why this matters more for group push than for a typical resource: there is no
API operation to retry a failed push. The management API exposes exactly five
group push operations (listGroupPushMappings, createGroupPushMapping,
getGroupPushMapping, updateGroupPushMapping, deleteGroupPushMapping),
verified against the 2026.03.0 spec and the current Go SDK. Retrying is an
Admin Console action with no programmatic equivalent.
That combination is the problem. A mapping can sit in status = "ACTIVE" with a
failing push and a populated errorSummary, and Terraform will report no drift
and show nothing wrong, because it never read the field. The operator has to go
to the console to discover the failure and again to fix it. Surfacing
error_summary and last_push would at least let a terraform refresh or a
state query reveal the failure, and would let downstream tooling alert on it.
We are weighing whether to manage our group push mappings as code at all, and
this gap is currently an argument against doing so: adopting Terraform here
would reduce what our operators can see, not increase it. That seems like the
opposite of the intended tradeoff.
Suggested shape: add error_summary, last_push, created and last_updated
as Computed-only string attributes and populate them in
mapPushGroupResourceToState. Being computed-only and absent from
configuration, they cannot produce a spurious diff. Happy to raise the PR if
maintainers agree on the approach and the attribute naming.
New or Affected Resource(s)
Customer Information
Organization Name: (redacted — large paid enterprise org, happy to share privately)
Paid Customer: yes
Potential Terraform Configuration
resource "okta_push_group" "example" {
app_id = "0oaXXXXXXXXXXXXXXXXX"
source_group_id = "00gXXXXXXXXXXXXXXXXX"
status = "ACTIVE"
delete_target_group_on_destroy = false
}
# Proposed: read-only diagnostics, so a failing push is visible without
# opening the Admin Console.
output "push_failure" {
value = okta_push_group.example.error_summary
}
output "pushed_at" {
value = okta_push_group.example.last_push
}
References
Community Note
Description
okta_push_groupdiscards the diagnostic fields the API already returns, whichmakes a Terraform-managed mapping strictly less observable than the same mapping
viewed in the Admin Console.
GET /api/v1/apps/{appId}/group-push/mappings/{mappingId}returnserrorSummary,lastPush,createdandlastUpdated. The Go SDK models allfour on
GroupPushMappingwith full accessors (GetErrorSummary,GetLastPush,GetCreated,GetLastUpdated), in the very same struct theprovider already reads
statusandtargetGroupIdfrom.mapPushGroupResourceToStatewrites onlyid,source_group_id,target_group_id,statusandapp_config. The schema has no attribute forany of the four, and
errorSummary/lastPushdo not appear anywhere inresource_okta_push_group.go. So the data is fetched and dropped.Why this matters more for group push than for a typical resource: there is no
API operation to retry a failed push. The management API exposes exactly five
group push operations (
listGroupPushMappings,createGroupPushMapping,getGroupPushMapping,updateGroupPushMapping,deleteGroupPushMapping),verified against the
2026.03.0spec and the current Go SDK. Retrying is anAdmin Console action with no programmatic equivalent.
That combination is the problem. A mapping can sit in
status = "ACTIVE"with afailing push and a populated
errorSummary, and Terraform will report no driftand show nothing wrong, because it never read the field. The operator has to go
to the console to discover the failure and again to fix it. Surfacing
error_summaryandlast_pushwould at least let aterraform refreshor astate query reveal the failure, and would let downstream tooling alert on it.
We are weighing whether to manage our group push mappings as code at all, and
this gap is currently an argument against doing so: adopting Terraform here
would reduce what our operators can see, not increase it. That seems like the
opposite of the intended tradeoff.
Suggested shape: add
error_summary,last_push,createdandlast_updatedas
Computed-only string attributes and populate them inmapPushGroupResourceToState. Being computed-only and absent fromconfiguration, they cannot produce a spurious diff. Happy to raise the PR if
maintainers agree on the approach and the attribute naming.
New or Affected Resource(s)
Customer Information
Organization Name: (redacted — large paid enterprise org, happy to share privately)
Paid Customer: yes
Potential Terraform Configuration
References
okta/services/idaas/resource_okta_push_group.go— schema attributes andmapPushGroupResourceToStateokta/model_group_push_mapping.go—ErrorSummary,LastPush,Created,LastUpdatedokta_push_groupreports: okta_push_group throw 404 error instead of being recreated #2807, Okta Push Group Import #2827, okta_push_group fails with HTTP 400 when linking AWS IAM Identity Center groups by name #2894,okta_push_group: failed delete after successful deactivation leaves state showing ACTIVE while group push has stopped #2903