# Manus Slow Query Diagnostic Fields

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "manus-slow-query-fields-2026-07-21",
  "problems": [
    {
      "problemId": "manus-slow-query-unselected-diagnostic-fields",
      "summary": "Manus Slow Query requests omit the fields projection, so supported scan, Cop wait, and RocksDB values look like zero.",
      "status": "optimized_verified",
      "issueKeys": ["*"],
      "sourceRefs": [],
      "signalTextIncludesAny": ["manus slow query fields", "manus process_keys", "manus total_keys", "vida slow query"],
      "observedThrough": "2026-07-21",
      "effectiveAt": "2026-07-21T11:04:06+08:00",
      "verifiedAt": "2026-07-21T11:05:52+08:00",
      "attemptedAction": "Select supported Manus Slow Query diagnostic fields before interpreting zero-valued scan and wait evidence.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/394"
    }
  ]
}
-->

- Optimization ID: `manus-slow-query-fields-2026-07-21`
- Owner: auto-oncall-services
- Source type: bundled Manus transport skill improvement
- Source reference: staging `vida` capability and response-shape baseline
- Bounded problem: `manus-op-grafana` calls `/api/slow_query/list` without a
  `fields` projection. Although `vida` advertises the diagnostic fields, the
  list response exposes their Go default values, which can be misread as real
  zero evidence.

## Status

- Implementation: merged in aisupport PR
  https://github.com/tidbcloud/aisupport/pull/394 and synced by app-delivery PR
  https://github.com/tidbcloud/app-delivery/pull/75024.
- Effective/deployment: available in staging since 2026-07-21 11:04 +08:00 on
  image `4343b55c0c4fda11ffb99de6fdb0a84c7596bbde`.
- Problem status: `optimized_verified`

## Baseline evidence

- On 2026-07-21, staging `vida` health succeeded on Dashboard
  `8.5.0-bce95733` / PD `v8.5.1`.
- `/api/slow_query/available_fields` returned 67 fields and included
  `process_keys`, `total_keys`, Cop timing, wait timing, and RocksDB counters.
- The existing no-`fields` request returned five rows whose diagnostic values
  were all zero or empty, reproducing the ambiguity.

## Post-change verification

- The live Deployment and Recent Optimizer CronJob both reference image
  `4343b55c0c4fda11ffb99de6fdb0a84c7596bbde`; the Deployment is 1/1 Ready and
  `/healthz` returns `ok`.
- The deployed Manus script contains the diagnostic profile and calls
  `/api/slow_query/available_fields` before the list query.
- A post-change equivalent evaluation repeated the exact baseline window
  `1784600296..1784602096`. The default diagnostic profile selected 48
  supported fields, reported `unsupported_fields=[]`, and returned five rows.
- The first three rows returned `process_keys=482`, `total_keys=486`,
  `request_count=11`, `rocksdb_key_skipped_count=321`, plus non-zero Cop and
  wait timing. These same rows appeared as zero-valued diagnostic evidence in
  the pre-change no-`fields` baseline.

## Unresolved gaps and next action

- No Jira ticket was used as validation evidence, so there is no case-level
  Jira internal comment to refresh for this optimization.
- When a future Manus Jira case depends on scan amplification, rerun that case
  and verify the internal comment by its stable idempotency key before adding
  the ticket key to this record.