# Wetech TopSQL Narrow Window

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-topsql-narrow-window-2026-08-05",
  "problems": [
    {
      "problemId": "wetech-topsql-full-incident-window-times-out",
      "summary": "The Wetech evidence child sends a full one-hour incident window to the single-instance TopSQL summary endpoint, causing repeatable provider timeouts and wasting the serial evidence budget.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29231"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29231#problem:wetech-topsql-full-window-timeout"
      ],
      "signalTextIncludesAny": [
        "topsql_query_timeout",
        "TopSQL queried the full one-hour incident window",
        "serial evidence batch spends about one minute on a timed-out TopSQL query"
      ],
      "observedThrough": "2026-08-05",
      "effectiveAt": "2026-08-05T16:40:57Z",
      "verifiedAt": "2026-08-05T16:50:55Z",
      "attemptedAction": "Keep TopSQL in the one serial batch for CPU or duration spike cases and make the Wetech helper derive its exact TiDB instance and at-most-15-minute hotspot window from a preceding instance-labelled metric result; continue rejecting wider explicit windows without guessing a segment.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29231#comment-23279460"
    }
  ]
}
-->

- Optimization ID: `wetech-topsql-narrow-window-2026-08-05`
- Owner: auto-oncall-services and wetech-op-grafana
- Source reference: `APID-29231` replay
- Implementation status: deployed to staging and verified by same-cutoff replay
- Effective status: `optimized_verified`

## Bounded problem

The same-cutoff Wetech replay sent the full 3,600-second incident window to
the single-instance TopSQL summary endpoint. TopSQL returned
`topsql_query_timeout` after 54.366 seconds; the preceding replay failed the
same endpoint after 62.749 seconds. Slow Query and metric calls in the same
serial batch succeeded, so this is a query-width/provider-cost problem rather
than a general Dashboard authentication failure.

## Candidate implementation

- For a CPU or duration spike case, place a TiDB instance-labelled alignment
  metric before TopSQL in the same serial plan.
- Let TopSQL declare both `instanceFromQueryId` and `windowFromQueryId`; the
  helper selects the highest metric series, its exact instance, and its peak
  timestamp without a second agent turn.
- Center an at-most-900-second TopSQL window on that timestamp while keeping it
  inside the runner-owned historical interval.
- Make the Wetech batch helper reject over-900-second TopSQL locally before
  browser startup or Dashboard access, without restricting broader Prometheus
  alignment or 30-60 minute Slow Query requests.

## Verification

- Wetech helper contract tests pass 51/51, including local rejection at 901
  seconds, acceptance at exactly 900 seconds, and preservation of a one-hour
  Slow Query request. The adaptive batch test proves a preceding metric's exact
  instance and peak timestamp produce a centered 900-second TopSQL request.
- The first post-change replay `c04b9047-6bc9-4b7d-81c4-fde67e1f6792`
  omitted TopSQL because the initial child rule required the hotspot window to
  be known before execution. That exposed the missing adaptive-window
  dependency addressed by this revision; it is not verification of the new
  behavior.
- Auto-oncall full tests pass 648/648, and the Wetech child rule is asserted
  inside the exact delimited contract passed to the evidence child.
- Post-change replay `a546140e-6d6b-44b8-b47a-778f8a50f5af` used the
  runner-owned one-hour incident interval, selected exact TiDB instance
  `10.107.42.44:10080` from the alignment metric, centered a 900-second TopSQL
  request on its peak at `1784833238`, and completed TopSQL in 26.618 seconds
  with 11 records. The five-query serial provider batch completed in 72.156
  seconds with no failed query.
- The replay completed with HTTP 200 and DB run id `120025`. It updated the
  existing Jira internal comment `23279460` in place; readback returned
  `public=false`.

## Unresolved gaps

- The bounded TopSQL timeout is resolved. The full replay still took 504.287
  seconds because the evidence-child agent turn took 289.837 seconds although
  its deterministic provider batch took 72.156 seconds.
- The publication guard returned `human_required` for an independent typed
  workload-identity and causality-boundary issue. That does not invalidate the
  verified provider query path, but remains a separate diagnosis-quality gap.

## Next validation action

Monitor later Wetech spike cases for regression of `topsql_query_timeout` or a
TopSQL request wider than 900 seconds. Treat any recurrence as new evidence for
this problem rather than suppressing it at ticket level.