# GHA Triage Evidence Map

## Repository execution facts

- Target workflows are in `../../tidb-management-service/.github/workflows/`.
- Dedicated scenario dispatch inputs and matrix execution are defined in `e2e-openapi-dedicated-scenario.yaml`.
- Scenario runtime entry point: `../../tidb-management-service/functional-test/cases/openapidedicated/autogencase/Scenario_suite_test.go`.
- Request/expect schema: `../../tidb-management-service/functional-test/cases/openapidedicated/autogencase/model/generationsteps.go`.
- Request execution and logs: `../../tidb-management-service/functional-test/cases/openapidedicated/autogencase/action.go`.
- Stable scenario step name: `Run scenario cases`.
- Matrix job names include the YAML, such as `nonprod (sce_public_endpoint.yaml)`.

## Log shapes

- Step marker: `DEBUG: do step, case:<id>, operation:<operation>, order:<n>, request_type:<type>, saved_placeholder:<map>`
- HTTP evidence: `DEBUG: http request, url:<url>, method:<method>, request_body:<body>, resp_header:<headers>, resp_body:<body>, status_code:<code>`
- Expect mismatch: `response is unexpected, expression:<json>`
- Failure marker: `do action failed, scenario:<yaml>, case:<id>, order:<n>`
- Trace header: `X-Debug-Trace-Id`.

## Historical sample facts (sanitized)

A recent Dedicated GCP failure had ten matrix jobs fail in `Run scenario cases`. One case polled 61 times for HTTP 200 with `body.state == "ACTIVE"`; the final response remained `CREATING`. Another recent Azure run mixed `Run scenario cases` failures with an `Install mysqlsh` failure, proving that classification must occur per failed job rather than once per workflow run.

## Security facts

Historical logs contain unmasked workflow-dispatch inputs, including API credentials, account fields, and SAS values. `saved_placeholder` can repeat those values. GitHub does not automatically mask arbitrary dispatch inputs. Raw logs therefore cannot be persisted, sent to an agent, or included in notifications; deterministic redaction must happen first.

The existing downstream workflow also contains a hard-coded Feishu webhook and SAS-bearing default configuration. This v1 does not modify that sibling repository, but it must not copy those values and must document rotation/remediation as an external follow-up.

## API facts

- GitHub REST API `2026-03-10` lists runs for one workflow under `/actions/workflows/{workflow}/runs`.
- The list endpoint supports `branch`, `status`, `created`, `per_page`, and `page`. A filtered search returns at most 1,000 results, so the client also applies its own smaller configured page cap.
- The monitor queries `status=completed`, filters abnormal conclusions locally, and uses `updated_at` against the persistent first-start baseline.
- Current-attempt jobs are available under `/actions/runs/{run_id}/attempts/{attempt}/jobs`.
- Per-job log download keeps matrix evidence isolated and smaller than a full-run ZIP.
- GitHub scheduled workflows can be delayed during high load. This is one reason the persistent watcher is run by a normal process manager instead of a chained schedule workflow.

## Feishu delivery facts

- A custom-bot webhook is bound to the group where the bot was created.
- A root message sent to a topic-form group appears as a topic.
- Replying inside an existing topic or addressing a `thread_id` requires the Feishu application-bot message APIs; a custom webhook cannot provide that control.