# Intake Test Failure

> Process raw failure info (GitHub issue URL, direct prompt text, GCS debug log links, or local logs) and normalize it into a clean failure payload for test fixing.

- Skill: `googlecloudplatform/intake-test-failure` (Agent Skill)
- Install (CLI): `npx skillmds@latest add googlecloudplatform/intake-test-failure`
- Raw SKILL.md: https://api.skillmd.com/api/skills/googlecloudplatform/intake-test-failure/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: GoogleCloudPlatform (https://skillmd.com/u/googlecloudplatform)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/googlecloudplatform/intake-test-failure

---


# `intake-test-failure`

This skill converts raw, unstructured, or varied failure reports into a standardized **Normalized Failure Payload** ready for consumption by the `test-fixer` subagent or developer remediation workflow.

## Prerequisites
* `gcloud` CLI installed and authenticated with access to `gs://nightly-test-data` or target GCS log buckets (requires `roles/storage.objectViewer` permission). If permission or authentication fails when running `gcloud storage`, verify login via `gcloud auth login`.
* `gh` CLI installed (optional, for querying GitHub issues).

## Input Formats Handled

1. **GitHub Issue URL** (e.g., `https://github.com/hashicorp/terraform-provider-google/issues/28244`)
2. **Direct Text Prompt** (Test name, error message, and optional log snippet/URL)
3. **GCS / Remote Log URL** (e.g., `https://storage.googleapis.com/...` or `gs://...`)
4. **Local Log File** (e.g., `test_output.log` or debug log file)

---

## Execution Steps

### Step 1: Extract Core Failure Information

#### Path A: GitHub Issue URL
- Use `read_url_content` (or `gh issue view` if CLI available) to read the issue content and inspect its GitHub labels.
- Check if labels contain `test-failure`, `test-failure-100`, `test-failure-50`, or any similar `test-failure*` labels to confirm this is an acceptance test failure issue.
- **Determine Target Provider Version (`ga`, `beta`, or `both`)**:
  - Inspect the issue `Failure rates` section:
    - If GA failure rate > 0% and Beta == 0%, set `target_provider: "ga"`.
    - If Beta failure rate > 0% and GA == 0%, set `target_provider: "beta"`.
    - If both GA and Beta failure rates > 0%, set `target_provider: "both"`.
  - Match provider-specific GCS error message links in the issue body:
    - `ga error message` (e.g. `.../test-errors/ga/.../*.txt`)
    - `beta error message` (e.g. `.../test-errors/beta/.../*.txt`)
  - **Fetch the complete content of each failing provider's error text file using `gcloud storage cat`** to populate `error_message` (if a GCS permission or authentication failure occurs, immediately report remediation instructions to check `gcloud auth login` and `roles/storage.objectViewer` access, and abort execution).
- Distinguish between **Error Message Links** and **Debug Log Links** in the issue body:
  - **Error Message Links**: Contain the exact `go test` output, backtraces, and `stdout` plan diffs for GA and/or Beta runs.
  - **Debug Log Links**: Contain the full `TF_LOG=DEBUG` provider trace (`ga debug log` / `beta debug log`). Fetch and process via `tf_debug_parser.py` for `parsed_logs_dir`.
- Search the issue body or fetched error log file for:
  - Impacted acceptance test name (e.g., `TestAcc<Resource>_<Scenario>`).
  - Full error text, backtrace, and `stdout` plan diff.

#### Path B: Direct Prompt / Text Entry
- Extract `test_name`, `target_provider` (`ga`, `beta`, or `both`), and full `error_message` directly from user input.
- Extract any GCS or local log paths provided.

#### Path C: Remote / GCS Log URLs
- Convert HTTPS GCS URLs (`https://storage.cloud.google.com/<bucket>/<path>` or `https://storage.googleapis.com/<bucket>/<path>`) to `gs://<bucket>/<path>`.
- For **Error Log links**, fetch the content using `gcloud storage cat`:
  ```bash
  gcloud storage cat gs://<bucket>/<path>
  ```
  Store the complete output in `error_message`.
- For **Debug Log links**, copy the file locally for parsing instead of printing to stdout:
  ```bash
  mkdir -p debug_output && gcloud storage cp gs://<bucket>/<path> debug_output/raw_test.log
  ```
- **Error Handling**: If `gcloud storage cat` or `gcloud storage cp` fails with a permission or authentication error (`permission denied`, `401`, `403`), immediately output an error message instructing the user to check `gcloud auth login` and ensure `roles/storage.objectViewer` access to the GCS bucket, and abort execution.

---

### Step 2: Log Parsing (If Debug Log Available)
If a debug log (local or GCS) is present:
- Run the `parse-debug-logs` skill:
  ```bash
  python3 .agents/scripts/tf_debug_parser.py <path_to_log> --extract-dir debug_output/<test_name>
  ```
- Inspect `debug_output/<test_name>/outline.txt` to capture relevant API HTTP request/response JSON file paths.

---

### Step 3: Produce Complete Normalized Failure Payload

Assemble and present the normalized payload in the following format. **CRITICAL: Include `target_provider` (`ga`, `beta`, or `both`) and do NOT truncate multi-line error output, assertion backtraces, or `stdout` plan diffs. Use a multi-line YAML block scalar (`|`) to preserve full error context:**

```yaml
normalized_failure_payload:
  test_name: "<ExactTestFunctionName>"
  target_provider: "ga"  # "ga", "beta", or "both"
  error_message: |
    <Full error output, go test backtrace, and stdout plan diff for GA and/or Beta>
  parsed_logs_dir: "debug_output/<test_name>/"  # Optional
```

---

## Next Step & Handoff

Pass the **Normalized Failure Payload** to the `test-fixer` subagent (`.agents/agents/test-fixer/`) to initiate automated diagnosis and remediation.