# Diagnostic Gap Ownership And Handoff

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "diagnostic-gap-ownership-2026-08-12",
  "problems": [
    {
      "problemId": "support-owned-query-gap-collapses-into-customer-evidence-shortage",
      "summary": "Failed, empty, or incomplete internal evidence acquisition could collapse into a generic insufficient-evidence customer conclusion, ask the customer for Support-queryable data, and omit the exact retry or escalation action from the Jira internal handoff.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29333"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29333#problem:support-owned-query-gap-reported-as-customer-evidence-shortage"
      ],
      "signalTextIncludesAny": [
        "evidence insufficient after internal query failure",
        "ask customer for metrics or component logs",
        "failed query has no internal escalation action",
        "human required progress lacks internal handoff"
      ],
      "observedThrough": "2026-08-12",
      "effectiveAt": "2026-08-12T11:50:24+08:00",
      "verifiedAt": "2026-08-12T12:15:38+08:00",
      "attemptedAction": "Make the Scenario Router classify failed, empty, causal, and customer-owned gaps; keep Provider-supported data owned by Support; constrain Final Response wording; allow gated human-required evidence progress updates; and always pair those public updates with a stable public=false Jira handoff containing the exact internal next action.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/tree/main/auto-oncall-services/docs/opts/2026-08-12-diagnostic-gap-ownership.md"
    }
  ]
}
-->

- Optimization ID: `diagnostic-gap-ownership-2026-08-12`
- Owner: auto-oncall-services Scenario Router, Final Response Agent, and Jira
  delivery path
- Source reference: `APID-29333`
- Implementation status: merged and deployed to staging as image
  `1992b9f9bfc336940f0aa7f0497758e90b7964ee`
- Effective status: `optimized_verified`

## Bounded problem

An internal Provider failure, empty result, or unresolved causal link could be
flattened into a customer-facing “insufficient evidence” conclusion. That could
reverse the next-action owner by asking the customer for Metrics, Slow Query,
Statements, or component logs that Support can query. The concise Jira internal
comment also omitted the exact failed scope, retry or alternative surface, and
escalation owner.

## Candidate change

- Make the Scenario Router distinguish Provider failure/degradation, completed
  empty results, completed-but-causally-open evidence, and genuinely missing
  customer-owned context.
- Keep Provider-supported Metrics, TopSQL, Slow Query, Statements, component
  logs, topology, and node mapping owned by Support after failed or empty
  queries.
- Require customer progress wording to preserve established facts, name the
  exact open boundary, and state Support's next action without generic
  “insufficient evidence” language or unsolicited “you do not need to provide
  logs” text.
- Permit a gated evidence-assisted `human_required` progress update after the
  selected Provider was attempted, while retaining all existing cohort,
  scenario, safety, validator, preflight, and idempotency boundaries.
- Pair every published progress update with a stable Jira internal comment that
  contains separate customer-progress and internal-handoff sections.

## Verification evidence

Local contract tests cover the Router and Final Response instructions, reply
format, publication gate, provider mismatch, improper customer Metrics request,
customer-visible progress write, independent `public=false` handoff write, and
internal handoff content. The complete test suite passed with 745 tests.

- Source PR [#807](https://github.com/tidbcloud/aisupport/pull/807) and
  app-delivery PR [#76920](https://github.com/tidbcloud/app-delivery/pull/76920)
  are merged. Staging rolled out image
  `1992b9f9bfc336940f0aa7f0497758e90b7964ee`; the Deployment completed and the
  replacement Pod passed `/healthz` and `/readyz`.
- Post-deployment `mode=read` replay
  `85c4a026-0dce-4fb1-8ee1-ce31005f3ba2` used the historical reply cutoff at
  comment `23528214`. It returned `human_required` with
  `requestedContext=[]`: established CPU facts remained in the customer
  progress, while failed or empty refinement queries, the alternative internal
  views, and the TiKV/PD escalation condition remained Support-owned in the
  internal handoff.
- A subsequent `mode=write` replay was interrupted by a Pod OOM restart before
  it persisted a new run. Using the already verified read-replay body, the
  authorized one-time recovery path updated existing Jira internal comment
  `23528578` directly. Readback at `2026-08-12T12:15:38+08:00` confirmed the
  same comment ID, `public=false`, the separated `【客户进展】` and `【内部交接】`
  sections, and no request for customer-provided Metrics or component logs.

## Unresolved gaps

- The interrupted write replay did not create a replacement DB run, so DB and
  downstream evaluation views continue to reflect the prior run rather than
  the directly recovered Jira body. No DB, evaluation, or Base history was
  rewritten.
- The replay Pod OOM restart is a separate runtime-capacity signal and is not
  evidence against this wording and ownership optimization.

## Next validation action

Treat a later recurrence that asks customers for Provider-queryable Metrics or
logs, or omits the internal retry and escalation owner, as regression evidence.
Investigate replay memory pressure as a separate operational problem before
running additional concurrent write replays.