# Clinic Diagnostic Extrema Compaction

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "clinic-diagnostic-extrema-compaction-2026-08-06",
  "problems": [
    {
      "problemId": "clinic-metric-series-prefix-truncation-drops-alerting-node",
      "summary": "Clinic metric compaction kept the first 20 provider series, so an alerting or extreme node later in the provider order could disappear from the scenario packet.",
      "status": "optimized_verified",
      "issueKeys": ["ST-2865"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/ST-2865#problem:clinic-prefix-truncation-dropped-alerting-tikv"
      ],
      "signalTextIncludesAny": [
        "metric series truncation dropped the alerting node",
        "clinic kept only the first twenty series",
        "extreme series was absent from compact evidence"
      ],
      "observedThrough": "2026-08-06",
      "effectiveAt": "2026-08-06T08:59:29Z",
      "verifiedAt": "2026-08-06T10:04:56Z",
      "attemptedAction": "Replace prefix truncation with deterministic extrema-preserving metric-series selection that retains high, low, last-value, and range outliers within the same 20-series output budget.",
      "evidenceUrl": "https://pingcap.feishu.cn/docx/SDHAdVVOXoCCfJxpduOcX2hKnAh"
    }
  ]
}
-->

- Optimization ID: `clinic-diagnostic-extrema-compaction-2026-08-06`
- Owner: auto-oncall-services
- Source reference: post-deployment `ST-2865` replay
- Implementation status: deployed to staging in image
  `ccdf46c1d66ffa98c2ea6eb86b09ba5a3c5b3add`; the change remains present in
  live descendant image `c481635f4b37b2f6e96c90d3615e13da9f138f8d`
- Effective status: `optimized_verified`

## Bounded problem

The compact evidence budget is necessary, but provider order is not diagnostic
priority. Prefix truncation can omit an alerting node when a metric returns more
than 20 series.

## Common-sense invariants

- Preserve the highest maximum and last value for high-is-bad metrics.
- Preserve the lowest minimum and last value for low-is-bad metrics.
- Preserve the widest range and largest first-to-last movement for transient
  or changing signals.
- Keep the output at no more than 20 series and remain deterministic.
- Do not infer metric semantics or label a selected extreme as a root cause.

## Verification status

The helper now selects a deterministic mixture of highest/lowest maximum,
minimum, average, and last values plus the widest range and largest
first-to-last movement. A synthetic 36-series case proves that high, low, and
moving series at provider indexes 33-35 survive the unchanged 20-series
budget. The complete repository suite passes 668/668.

The first post-deployment source replay, run
`1e7db950-7f57-4292-92b0-259ac243e659` / DB run `120036`, did not exercise the
compactor because no Clinic batch materialized. A later replay on live image
`c481635f4b37b2f6e96c90d3615e13da9f138f8d`, run
`b28a225a-23df-4e65-9f84-ec470808e142` / DB run `120045`, produced and
validated the Clinic batch.

The live alignment query compacted 60 series to 20 and the allocator mechanism
query compacted 324 series to 20. Both reports recorded
`selectionStrategy=diagnostic_extrema_v1`. The selected evidence preserved the
largest TiKV container working-set series at approximately 98.5-100.6 GiB and
the aligned allocator resident, retained, and fragmentation extrema. The final
draft used those bounded observations without asserting an unsupported
workload cause, OOM, or restart.

The replay updated existing Jira internal comment `23432370` in place. Exact
readback returned HTTP 200 and `public=false`; the body retained the working-
set, retained-memory, and fragmentation facts. Together with the deterministic
36-series and three-series controls, this satisfies the problem criterion.

## Unresolved gaps

- Extrema preservation does not prove that the selected high-memory instance is
  the alert source or root cause; entity alignment and causal admission remain
  separate diagnosis responsibilities.
- This change preserves useful series inside a fixed batch; it does not make
  the provider plan adaptive after seeing an initial result.

## Next validation action

Monitor later greater-than-20-series Cloud cases for regressions. Reopen this
problem only if a diagnostically extreme series is again omitted under
`diagnostic_extrema_v1`; treat child orchestration and adaptive query planning
as separate problem signals.