### Summary `gitlab_group_service_account_access_token` deletion (including as part of a forced replace) fails for a top-level group **Owner** on GitLab.com SaaS, even though the GitLab API supports revoking a service account's access token at that permission level via a dedicated endpoint. See Root cause below. ### Terraform, provider and GitLab versions - Terraform: v1.15.8 - terraform-provider-gitlab: v19.0.0 - GitLab: gitlab.com (SaaS) ### Affected resource(s) - `gitlab_group_service_account_access_token` ### Terraform configuration ```hcl resource "gitlab_group_service_account_access_token" "main" { group = gitlab_group_service_account.main.group user_id = gitlab_group_service_account.main.service_account_id name = "test" scopes = ["api"] rotation_configuration = { expiration_days = 365 rotate_before_days = 200 } } ``` The token was originally created outside this Terraform config and brought under management with an `import` block: ```hcl import { id = "12345678:87654321:11223344" to = gitlab_group_service_account_access_token.main } ``` ### Steps to reproduce 1. As a top-level group **Owner** (not a GitLab.com instance admin) on gitlab.com, `terraform import` an existing `gitlab_group_service_account_access_token`. 2. Run `terraform plan` to trigger a forced replacement of that resource. 3. Run `terraform apply`. ### Expected behavior The provider revokes the service account access token using the group-scoped GitLab API endpoint: ``` DELETE /groups/:id/service_accounts/:user_id/personal_access_tokens/:token_id ``` This matches what the provider's own code already assumes elsewhere in this same resource file: - `Create()` calls `r.client.Groups.CreateServiceAccountPersonalAccessToken(...)` directly. - `Update()` (rotation) calls `r.client.Groups.RotateServiceAccountPersonalAccessToken(...)` directly and **unconditionally** — no admin check at all (`resource_gitlab_group_service_account_access_token.go:728`). It only falls back to a self-rotate path when the *user* has deliberately added `self_rotate` to the token's own scopes, which is an opt-in feature, not a permission fallback. `Delete()` is the odd one out: it never calls the equivalent `Groups.RevokeServiceAccountPersonalAccessToken(...)`, even though that endpoint exists in the same `client-go` library version this provider already depends on, and even though `Create`/`Update` prove it works for Owner-level callers on gitlab.com SaaS. ### Actual behavior ``` Error: Error deleting group service account access token Could not create a new client with the token that exists in state. The provider's token can't delete the service account access token because it's not an admin (top-level group owner on gitlab.com): The provider failed to create a new GitLab Client from the given configuration: unable to locate config file ``` ### Root cause In `internal/provider/resource_gitlab_group_service_account_access_token.go`, `Delete()` (around line 749) does: ```go isAdmin, err := api.IsCurrentUserAdmin(ctx, r.client) ... if isAdmin { // direct delete via generic admin endpoint _, err = r.client.PersonalAccessTokens.RevokePersonalAccessTokenByID(accessTokenIDInt, ...) } else { // self-revoke fallback using the plaintext token value stored in state tokenClient, err := r.newGitLabClient(ctx, WithToken(data.Token.ValueString()), WithEarlyAuth(false)) ... _, err = tokenClient.PersonalAccessTokens.RevokePersonalAccessTokenSelf(ctx) } ``` Two separate problems compound here: 1. **`IsCurrentUserAdmin` is effectively never `true` for a regular user on gitlab.com SaaS.** Top-level group Owner is an unrelated, group-scoped permission that this check never looks at. 2. **The group-scoped revoke endpoint is never used by `Delete()`, unlike `Create()`/`Update()` in the same file.** The underlying `client-go` library already exposes it: ```go // groups.go RevokeServiceAccountPersonalAccessToken(gid any, serviceAccount, token int, options ...RequestOptionFunc) (*Response, error) ``` which maps to `DELETE /groups/:id/service_accounts/:user_id/personal_access_tokens/:token_id`. 3. **The self-revoke fallback is unusable for imported resources.** `WithToken(data.Token.ValueString())` uses the token value from Terraform state. GitLab never returns a PAT's plaintext value after creation, so any token brought into Terraform via `import` (or refreshed without ever going through `Create`) has an empty `token` attribute in state. In `internal/provider/api/config.go:34-60`: ```go if c.Token == "" { // Assuming that the configuration is made via file ... cfg := config.New(options...) if err := cfg.Load(); err != nil { return nil, err } ... } ``` An empty token is silently interpreted as "load a `glab`-style CLI config file instead," which doesn't exist in a Terraform/CI context, producing the confusing `unable to locate config file` error nested inside the original one. ### Suggested fix - Make `Delete()` call `r.client.Groups.RevokeServiceAccountPersonalAccessToken(group, userID, tokenID)` directly, the same way `Create()` and `Update()` already call their group-scoped counterparts — dropping (or at least de-prioritizing) the `IsCurrentUserAdmin`/self-revoke path for this resource entirely, since the group-scoped endpoint already covers the permission level this resource is designed to be managed under. - If the admin/self-revoke fallback is kept for some other reason, at minimum fix `internal/provider/api/config.go`'s empty-token branch to fail fast with a clear error ("no token available to build this client") instead of silently trying to load a `glab`-style CLI config file that will essentially never exist in a Terraform/CI context. ### Related issues - [#6410](https://gitlab.com/gitlab-org/terraform-provider-gitlab/-/issues/6410) — same `Delete()` code path; concluded that group Owner is insufficient to revoke a service account token via the generic PAT API, and fixed the immediate symptom by adding the self-revoke fallback (now in `Delete()`). That conclusion appears to be outdated/incorrect for the group-scoped endpoint specifically — see Root cause above, and the fact that `Update()`'s rotate path already relies on group-Owner access via the equivalent endpoint without issue.