<details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/engineering/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Label this issue](https://contributors.gitlab.com/manage-issue?action=label&projectId=40916776&issueIid=6900) </details> ## Bug Report When `mirror_branch_regex` is set on a `gitlab_project_pull_mirror` resource, the initial `terraform apply` (create) succeeds, but any subsequent in-place update of the resource (for example rotating `auth_password`) fails against GitLab 19.5+ with: ``` Error encountered: PUT https://gitlab.com/api/v4/projects/<id>/mirror/pull: 400 {error: only_mirror_protected_branches, mirror_branch_regex are mutually exclusive} ``` ### Root cause GitLab 19.5 changed `PUT /projects/:id/mirror/pull` so that sending both `only_mirror_protected_branches` and `mirror_branch_regex` now returns `400 Bad Request`, even when `only_mirror_protected_branches` is `false`. Previously the API silently forced the flag to `false`. See https://gitlab.com/gitlab-org/gitlab/-/issues/627615 and the API docs: https://docs.gitlab.com/api/project_pull_mirroring/#update-project-pull-mirroring-settings ("Omit `only_mirror_protected_branches` when using this attribute. Sending both returns `400 Bad Request`, even when `only_mirror_protected_branches` is `false`.") In `internal/provider/resource_gitlab_project_pull_mirror.go`, `only_mirror_protected_branches` is `Optional + Computed` with `boolplanmodifier.UseStateForUnknown()`: - On **create**, the value is unknown, so `updateProjectPullMirrorConfig` does not send it and the request succeeds. - On **update**, `UseStateForUnknown` copies the value from state (`false`, as read back from the API in `mapMirrorToModel`). The value is then known and non-null, so the provider sends `only_mirror_protected_branches=false` together with `mirror_branch_regex`, triggering the 400. There is no config-side workaround: explicitly setting `only_mirror_protected_branches = false` (or `null`) fails plan validation because both attributes carry a `ConflictsWith` validator against each other. ### Relevant Terraform Configuration ```hcl resource "gitlab_project_pull_mirror" "example" { project = gitlab_project.project.id url = var.git_pull_mirror_url mirror_branch_regex = var.git_pull_mirror_branch_regex auth_password = var.git_pull_mirror_password } ``` ### Relevant Terraform Command `terraform apply` (second run, or any run that produces an in-place update of the resource) ### Relevant Log Output ``` Error encountered: PUT https://gitlab.com/api/v4/projects/83741950/mirror/pull: 400 {error: only_mirror_protected_branches, mirror_branch_regex are mutually exclusive} ``` ### Suggested fix In `updateProjectPullMirrorConfig`, do not forward `only_mirror_protected_branches` when `mirror_branch_regex` is set in the plan (and, symmetrically, do not forward `mirror_branch_regex` when `only_mirror_protected_branches` is set). Alternatively, drop `UseStateForUnknown` on these two attributes so a value that is not in configuration stays unknown/null and is omitted from the request. The same check may be worth applying to the pull mirror handling in the `gitlab_project` resource. ### Workarounds - `terraform apply -replace=gitlab_project_pull_mirror.example` so the change goes through create instead of update. - Temporarily use `only_mirror_protected_branches` instead of `mirror_branch_regex`. ### Environment - GitLab Instance: GitLab.com (19.5) - Terraform provider: latest (`main` still exhibits the pattern described above) ## Implementation plan *Added by [GitLab Duo Agent Platform 🤖](https://gitlab.com/components/agents-and-flows/quick-win-labeller)* 1. **Locate the update function** in `internal/provider/resource_gitlab_project_pull_mirror.go` — find `updateProjectPullMirrorConfig` (or the equivalent `Update` method). 2. **Add mutual-exclusion guards** before populating the API options struct: - Only send `only_mirror_protected_branches` when `mirror_branch_regex` is null/unknown in the plan (i.e. not configured by the user). - Only send `mirror_branch_regex` when `only_mirror_protected_branches` is null/unknown in the plan. - Use `data.MirrorBranchRegex.IsNull() && data.MirrorBranchRegex.IsUnknown()` style checks (consistent with the existing provider pattern for guarding Optional+Computed fields before API calls). 3. **Optionally**, consider whether `boolplanmodifier.UseStateForUnknown()` on `only_mirror_protected_branches` should be replaced with `boolplanmodifier.UseNonNullStateForUnknown()` or removed entirely, so that an unconfigured value stays unknown and is naturally omitted from the request body. 4. **Check `gitlab_project` resource** — apply the same guard to any pull-mirror update logic in `internal/provider/resource_gitlab_project.go` if it has a similar code path. 5. **Write or update acceptance tests** to cover the scenario: create a pull mirror with `mirror_branch_regex`, then perform an in-place update (e.g. change `auth_password`), and assert no 400 error occurs.