# OP Handoff Load-Bearing Facts

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "op-handoff-load-bearing-facts-2026-08-11",
  "problems": [
    {
      "problemId": "op-handoff-drops-slow-query-memory-attribution",
      "summary": "The Provider Executor reduced each compact OP result to three categorical fields, six numeric fields, and a 1000-character statement, dropping an aligned Slow Query ANALYZE identity and its memory_max before the Scenario Diagnostic Agent could assess memory attribution.",
      "status": "optimized_unverified",
      "issueKeys": ["APID-29296"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29296#problem:op-handoff-drops-slow-query-memory-attribution"
      ],
      "signalTextIncludesAny": [
        "memory_max omitted from handoff",
        "three categorical and six numeric fields",
        "1000 character factual suffix",
        "Slow Query peak memory unavailable to Scenario Diagnostic Agent"
      ],
      "observedThrough": "2026-08-11",
      "effectiveAt": "2026-08-11T21:21:28+08:00",
      "verifiedAt": null,
      "attemptedAction": "Preserve up to five TopSQL rows and ten Slow Query rows, raise a complete query fact to 16 KiB and the cumulative Scenario handoff to 128 KiB, retain all allowlisted load-bearing identity, instance, timing, and memory fields that fit, derive safe statement identity without raw SQL, and omit whole lower-priority query observations with an explicit summary only when the cumulative byte budget is exceeded.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29296?focusedCommentId=23399342"
    }
  ]
}
-->

- Optimization ID: `op-handoff-load-bearing-facts-2026-08-11`
- Owner: auto-oncall-services Provider Executor
- Source reference: `APID-29296` staging replay
- Implementation status: deployed to staging in image
  `58044ba98a38ad6238b4ad5979e5625cbe1be893`
- Effective status: `optimized_unverified`

## Bounded problem

The staged `APID-29296` Provider compact report contained an aligned
`ANALYZE TABLE` Slow Query on TiDB instance `10.164.19.243:10080`, including
about 294 seconds of query time and a `memory_max` value of 46,295,458,134
bytes. The deterministic handoff admitted fields by fixed key order and stopped
after three categorical and six numeric fields, then bounded the whole fact to
1,000 characters. The Scenario Diagnostic Agent consequently received neither
the safe statement identity nor peak memory and could not consider this
candidate in its memory attribution.

This record owns deterministic compact-fact capacity and priority only. It does
not assert that temporal overlap alone proves the query caused the cluster
memory increase.

## Candidate change

- Keep at most five TopSQL rows and ten Slow Query or other ranked rows.
- Allow one compact query fact up to 16 KiB and one cumulative four-round
  Scenario handoff up to 128 KiB.
- Preserve all allowlisted categorical and numeric fields that fit, with
  workload identity, instance, timestamp, query time, and peak memory ordered
  before supporting phase metrics.
- Derive safe statement type, object, and ANALYZE options without exposing raw
  SQL, plans, Digests, or arbitrary provider strings.
- Ask the Evidence Agent to order queries from most to least load-bearing. If
  the cumulative budget is exceeded, drop whole later observations and name
  the omitted query IDs while retaining query coverage and canonical compact
  report references.

## Verification evidence

Local regression tests cover ten Slow Query rows with peak-memory attribution,
five TopSQL rows, a query fact longer than 1,000 characters, and whole-query
filtering at the cumulative 128 KiB boundary. The complete suite passed 750
tests.

Staging image `58044ba98a38ad6238b4ad5979e5625cbe1be893`
reached 1/1 Ready with zero restarts, and `/healthz` plus `/readyz` returned
HTTP 200. Same-cutoff `mode=write` replay
`2ccf8aa6-5032-4728-ae78-bb3f40e0f0fd` / DB run `120078` completed with
Provider acquisition `complete` and no Provider failure codes. The materialized
handoffs demonstrated the new boundary directly:

- each TopSQL result retained exactly five rows and reported
  `top_rows_retained=5/10`;
- Slow Query results retained ten rows with complete allowlisted facts,
  including `instance`, `timestamp`, `query_time`, and `memory_max` whenever
  those fields were returned by the Provider;
- the query-latency handoff retained the 294.2518-second ANALYZE identity,
  object, instance, and ANALYZE options; its cumulative two-round handoff was
  34,866 bytes, below the 128 KiB budget;
- no 1,000-character, three-categorical, or six-numeric truncation remained.

The existing Jira internal comment `23399342` was updated in place and read
back with `public=false`. The replay does not promote this problem to
`optimized_verified`, because the corrected final analysis criterion did not
pass.

## Unresolved gaps

- The query-latency Slow Query plan requested the 294.2518-second ANALYZE record
  but did not request `memory_max`. The memory scenario requested
  `memory_max`, but its default first ten records did not include that late
  ANALYZE. The target statement identity and peak memory therefore still did
  not coexist in one fact supplied to a Scenario Diagnostic Agent.
- An aligned Slow Query `memory_max` makes the query a material candidate, but
  the Scenario Diagnostic Agent must still distinguish correlation from a
  complete causal mechanism.
- Final publication also applied a COMMIT/`prev_stmt` identity boundary that
  was unrelated to this ANALYZE case, replacing the useful diagnosis tail with
  a generic write-attribution warning. This is a separate synthesis/publication
  problem rather than a handoff-capacity failure.

## Next validation action

Change the acquisition objective so a memory-related latency case requests
`memory_max` on the latency-ranked Slow Query records, then replay
`APID-29296`. Separately scope the typed write-identity publication boundary so
it cannot inject COMMIT/`prev_stmt` guidance into an ANALYZE-only diagnosis.