Skip to content

okta_push_group: surface errorSummary and lastPush from the API #2907

Description

@exitcode0

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)

  • okta_push_group

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions