run_53d4eba869cfe299

input

{
  "request": "Triage Jira ticket MZCLD-3661: projects/tf batch settings",
  "references": [
    "https://mozilla-hub.atlassian.net/browse/MZCLD-3661"
  ],
  "sourceContext": {
    "issue": "MZCLD-3661"
  }
}

summary

MZCLD-3661 tracks rolling out the Terraform GCP provider's `batching` block (specifically a shorter `send_after` interval, e.g. 500ms) across `projects/tf/**` to cut down plan times that were dominated by refreshing state for `google_project_service` (project_services) and IAM resources. The reporter already validated locally that this reduces plan time for `projects/tf/webservices` from ~20 min to ~6 min. The ticket is marked "In Progress" but has no comments yet, and the description hints at other directories with heavy IAM/project_services usage that could benefit similarly, but doesn't yet enumerate them or show a merged PR link (text appears to have redacted/stripped links, e.g. "After landing ," and "the GCP provider batch setting ( )"). No runbook or Confluence doc is referenced in the ticket, so no supplemental design doc context was available to pull.

findings

• Root cause identified: default GCP Terraform provider batching interval causes slow `terraform plan` due to refreshing large numbers of project_services and IAM resources.
• Fix is scoped narrowly: the batching setting only affects `project_services` and `iam` resource types, and current ticket scope is limited to `projects/tf/**`.
• Ticket explicitly calls out follow-up scope: other directories with many IAM resources could also benefit, but this isn't itemized yet, and no sub-tasks/linked tickets appear to have been created for that follow-up.
• Ticket is 'In Progress' with zero comments and no linked PR/Confluence reference visible in the description text (some content appears redacted/stripped, e.g. 'After landing ,' and blank parenthetical), making it hard to verify current implementation state or whether the change has already been applied/merged.

proposed actions

Triage note: This looks like a well-scoped perf fix (GCP provider `batching { send_after = "500ms" }` or similar) validated locally with a 20min→6min plan-time improvement for projects/tf/webservices, limited to project_services/iam resources. A few suggestions before closing out:

1. Since the description references 'after landing' a prior change and a specific batch setting value, could you link the PR(s) that introduced/tuned this setting so reviewers can confirm the exact config (e.g., send_after interval, whether it's set per-module or via a shared provider config)?
2. Please confirm whether this fix has been applied to all of projects/tf/** yet, or only to the webservices subdirectory tested locally — consider adding a checklist/subtask per directory if rollout is partial.
3. You mention other directories with lots of IAM resources could benefit similarly — recommend filing a follow-up ticket (or converting this into an epic with subtasks) to track that broader rollout so it doesn't get lost.
4. If this is otherwise complete and validated, please move to Done/Review and note the measured before/after plan times for the record.

Let us know if you need help identifying other IAM/project_services-heavy directories for the broader rollout.

tool calls

[
  {
    "capability": "jira.issue.read",
    "args": {
      "key": "MZCLD-3661"
    },
    "result": {
      "key": "MZCLD-3661",
      "summary": "projects/tf batch settings",
      "status": "In Progress",
      "description_text": "After landing    , we found that  gpa/projects/tf/webservices  was still taking ~~ 20 minutes to plan, mostly spent on refreshing the state on all billion of our enabled APIs. Further investigation led me to the GCP provider batch setting (   ) - local testing shows that settings this to 500ms significantly reduces plan time (from 20 min to ~~ 6 min). This setting only affects project_services and iam resources. This ticket covers enabling it for  projects/tf/** , but there\u2019s probably other places with lots of IAM resources where we can get more value out of it.",
      "comment_count": 0,
      "comments": []
    }
  }
]

log