# Wetech Dashboard Session Fail-Fast

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-dashboard-session-fail-fast-2026-08-11",
  "problems": [
    {
      "problemId": "wetech-batch-repeated-dashboard-session-wait",
      "summary": "One Wetech evidence batch repeated the same 300-second unavailable Dashboard session wait independently for slow-query, statements, and TopSQL operations.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29296"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/APID-29296#problem:wetech-repeated-dashboard-session-wait"],
      "signalTextIncludesAny": ["Dashboard session is not ready", "wetech_dashboard_session_unavailable", "digest wait"],
      "observedThrough": "2026-08-11",
      "effectiveAt": "2026-08-11T05:47:29Z",
      "verifiedAt": "2026-08-11T06:05:37Z",
      "attemptedAction": "After one Dashboard operation proves the session unavailable, preserve that bounded failure and fail later Dashboard operations in the same serial batch immediately while retaining already collected Prometheus evidence.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/tree/main/auto-oncall-services/docs/opts/2026-08-11-wetech-dashboard-session-fail-fast.md"
    }
  ]
}
-->

- Optimization ID: `wetech-dashboard-session-fail-fast-2026-08-11`
- Owner: auto-oncall-services
- Source: APID-29296 temporary-pod replay `ea75c3c9-d599-4f85-903a-d1a4a14074d9`
- Implementation status: deployed and runtime-verified in staging

## Bounded problem

The Wetech provider executes operations serially. In the observed replay, the
Prometheus queries completed, but slow-query and statements each spent 300
seconds reaching the same `TiDB Dashboard session is not ready` result; TopSQL
was then scheduled to repeat it again. This delay is Dashboard transport
readiness, not digest generation.

## Attempted change

Within one deterministic batch, the first explicit Dashboard-session-not-ready
failure remains the load-bearing attempt. Later slow-query, statements, or
TopSQL operations record `wetech_dashboard_session_unavailable` immediately.
Prometheus observations remain usable and the Scenario Diagnostic Agent can
finalize with the exact evidence gap.

## Verification status

Unit coverage verifies one provider call for three Dashboard operations after
the first session failure. Temporary-pod replay
`87f32f09-75ce-43dc-a84b-2af1192386d9` verified the same behavior twice: after
one load-bearing Dashboard wait in each scenario batch, later Dashboard
operations completed in 0 ms with
`wetech_dashboard_session_unavailable`, while Prometheus observations remained
available to the final answer. This was the pre-deployment runtime proof.

Shared staging replay `34eff525-726b-4f5f-b0b0-c9c6325a6d6b` on image
`6fcd789dfe896594b405cfdb0b8df7fc50a47fc3` reproduced the operational
criterion in both scenarios. After one load-bearing Dashboard operation failed,
the remaining Dashboard operations returned
`wetech_dashboard_session_unavailable` without repeating the session wait,
while the already completed Prometheus observations remained in each batch.

## Unresolved gaps

This does not repair the underlying Wetech Dashboard session. It prevents
duplicate waits and makes the common dependency failure explicit.

## Next validation action

Continue tracking the underlying Dashboard session as a separate provider
availability problem; do not repeat the same wait-reduction optimization.