# Wetech Binary Plan Dashboard Decode

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-binary-plan-dashboard-decode-2026-08-18",
  "problems": [
    {
      "problemId": "wetech-binary-plan-remained-encoded",
      "summary": "An exact-Digest Slow Query row contained binary_plan, but no decoded projection, so the compact handoff reported encoded_plan_only and the diagnosis could not use operator evidence.",
      "status": "optimized_verified",
      "applicability": "Wetech exact-Digest Slow Query requests whose incident-overlapping rows expose binary_plan without binary_plan_json or binary_plan_text.",
      "issueKeys": ["APID-29344"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/APID-29344#problem:wetech-binary-plan-remained-encoded"],
      "signalTextIncludesAny": ["encoded_plan_only", "binary plan was not decoded", "no operator details"],
      "observedThrough": "2026-08-19",
      "effectiveAt": "2026-08-19T00:57:14+08:00",
      "verifiedAt": "2026-08-19T10:22:15+08:00",
      "attemptedAction": "For at most three incident-overlapping Slow Query rows, use the authenticated TiDB Dashboard visualplan generate API to decode binary_plan and compact only the safe operator summary; preserve the row when decoding fails.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29344?focusedCommentId=23559192"
    }
  ]
}
-->

- Optimization ID: `wetech-binary-plan-dashboard-decode-2026-08-18`
- Owner: Wetech Provider Executor
- Source reference: `APID-29344`
- Implementation status: deployed in image `00add7fc3ad53efc10d99e6fa9e687b1fae3197c`
- Effective status: `optimized_verified`

## Bounded problem

Dashboard Slow Query returned the requested encoded binary plan, but the
Provider Executor only consumed already-decoded JSON or text. The structured
plan path therefore stopped at `encoded_plan_only` even though the same
authenticated Dashboard exposes a binary-plan decode operation.

## Change and validation

Decode only incident-overlapping rows, with a maximum of three authenticated
requests. Pass only the existing safe operator summary across the handoff. A
decode rejection is proportional to that optional field and leaves the Slow
Query row usable. Local tests cover the bound, overlap filter, safe compaction,
and failure behavior.

Read replay `c0d61d0c-0c64-41a6-8ae9-1d3b433036c4` decoded all three requested
incident plans with zero decode failures. The compact facts contained
`IndexHashJoin`, both `IndexLookUp`/`IndexRangeScan` branches, and
`estRows`/`actRows`. Write replay `24e31d39-7f22-4d93-8053-364d314b7f15`
again used complete operator facts in the answer instead of reporting
`encoded_plan_only`.

The write replay updated existing Jira internal comment `23559192`; direct
readback confirmed the expected text and `public=false`. Database run `150099`,
evaluation, and Feishu Base publication all succeeded.

## Separate remaining problem

This bounded decode problem is verified. The write replay was still judged
`human_better` because the diagnosis did not directly explain how estimated
Build/Probe cardinality and cost led the optimizer to choose `IndexHashJoin`.
That is a separate Scenario Diagnostic Agent semantics problem recorded in
`2026-08-19-index-hash-join-selection-explanation.md`; it does not invalidate
the decoded-plan capability.