# Wetech Dashboard Authentication Fail-fast

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-dashboard-auth-fail-fast-2026-08-14",
  "problems": [
    {
      "problemId": "wetech-dashboard-sql-auth-rejection-retried-as-readiness",
      "summary": "A deterministic TiDB Dashboard SQL credential rejection was retried as generic readiness across two configured routes, consuming about ten minutes before any TopSQL, Slow Query, or Statements request was sent.",
      "status": "optimized_verified",
      "applicability": "Wetech Dashboard-backed TopSQL, Slow Query, and Statements acquisition when the standard Dashboard SQL account or permission is not yet provisioned, or the SQL sign-in page otherwise explicitly rejects the configured credentials.",
      "issueKeys": ["APID-29343"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29343#problem:wetech-dashboard-auth-rejection-retried"
      ],
      "signalTextIncludesAny": [
        "Sign in failed: TiDB authentication failed",
        "wetech_dashboard_authentication_failed",
        "last_state=dashboard_login"
      ],
      "observedThrough": "2026-08-14",
      "effectiveAt": "2026-08-14T14:46:43Z",
      "verifiedAt": "2026-08-14T15:38:57Z",
      "attemptedAction": "Detect the explicit Dashboard SQL authentication rejection after one submitted login, return a typed terminal non-repairable result without trying a standby route, and share that result with later Dashboard operations in the same batch while preserving independent Metrics results.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29343?focusedCommentId=23563769"
    }
  ]
}
-->

- Optimization ID: `wetech-dashboard-auth-fail-fast-2026-08-14`
- Owner: Wetech Provider Executor session readiness and runner query-repair gate
- Source reference: `APID-29343`
- Implementation status: deployed to staging in image `9ebd2d3e8160d5321c62749043a32b9eb471396f`
- Effective status: `optimized_verified`

## Bounded problem

APID-29343 did not spend its long Provider interval executing an overly broad
query. The canonical Metrics window was one hour and its queries completed in
seconds. Dashboard-backed operations stopped before request construction: the
SQL sign-in page reported `Sign in failed: TiDB authentication failed`.

For APID-29343, this authentication response is the expected state while the
user has not yet provisioned the standard Dashboard SQL account and required
permissions. It is not evidence of a target-resolution, Perimeter81, Grafana,
Prometheus, or auto-oncall defect. The typed code is an internal terminal
execution result used to stop retries; it does not turn this expected external
precondition into a separate optimization failure.

The helper treated that deterministic rejection as generic readiness, retried
the login until the 300-second readiness limit, and then tried the second
configured Dashboard route. Concurrent Dashboard operations repeated the same
work. The generic error also allowed a same-round query repair to switch to
Statements even though Statements requires the same rejected Dashboard
session.

## Candidate change

- After one Dashboard SQL login submission, recognize only the explicit TiDB
  credential-rejection page and return
  `wetech_dashboard_authentication_failed` immediately.
- Do not try a standby Dashboard route for that typed credential rejection.
- Share the typed terminal result with later Dashboard operations in the same batch;
  preserve independent successful Metrics observations.
- Treat only this deterministic code as non-repairable. Keep generic session,
  transport, query, selector, filter, and window failures eligible for their
  existing bounded recovery.
- Preserve the runner-owned absolute window, TopSQL hotspot-window bound, and
  Slow Query/Statements filter parameters unchanged.

## Verification status

The focused Wetech helper contract suite passed `77/77`; the focused runner
suite passed `86/86`; TypeScript type checking passed; and the full repository
suite passed `824/824`. The helper tests prove one submitted credential
rejection returns the typed code without standby or query execution, later
Dashboard operations share that code, Metrics remain available, generic
session fallback still behaves as before, and the one-hour Slow Query window,
`job_task_record` filter, and result limit are unchanged.

PR `tidbcloud/aisupport#926` and app-delivery PR
`tidbcloud/app-delivery#77344` are merged. Staging Deployment
`auto-oncall-services` became Ready at `2026-08-14T14:46:43Z` with image
`9ebd2d3e8160d5321c62749043a32b9eb471396f`; `/healthz` and `/readyz` both
returned HTTP 200.

Frozen-cutoff read run `4075cf69-fad8-4938-951b-36794a3ab92a` returned
`wetech_dashboard_authentication_failed`, retained successful Metrics, shared
the typed failure with later Dashboard operations, did not enter the prior
same-round repair loop, and completed in 326 seconds instead of exhausting the
960-second scenario budget. Write run `59c96d40-948b-498a-be97-8ebca5df425f`
repeated the bounded behavior, received Judge verdict `ai_better`, persisted DB
run `150048`, evaluation, and Feishu updates without errors, and updated
existing Jira internal comment `23563769`. Direct readback verified
`public=false`. Preservation runs `355f6651-008c-48ac-b351-4e6b596c894a` and
`07c62d47-5c11-42dc-96e6-b35ef8163ad0` preserved ordinary repair and successful
Dashboard acquisition when the deterministic credential rejection was absent.
The problem is `optimized_verified`. The still-unprovisioned standard account
is an expected external precondition, not an unresolved problem in this
optimization.

## Next validation action

No repair is required from auto-oncall while the standard account and
permissions are intentionally not configured. Continue using successful
Metrics evidence and mark Dashboard-dependent SQL evidence unavailable. After
the user provisions the standard account, the existing readiness path can use
Dashboard evidence without another fail-fast optimization change.