# TiFlash Duplicate MPP Dispatch Knowledge

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "tiflash-duplicate-mpp-dispatch-2026-08-20",
  "problems": [
    {
      "problemId": "exact-tiflash-duplicate-registration-mechanism-not-applied",
      "summary": "The Scenario Router can receive an exact TiFlash task-is-already-registered error yet leave the known duplicate MPP dispatch mechanism as an unselected alternative and let generic resource evidence dominate the answer.",
      "status": "optimized_verified",
      "applicability": "TiDB or TiDB Cloud diagnostic tickets containing the exact TiFlash MPP duplicate-registration error, including Failed to register MPP Task with task is already registered.",
      "issueKeys": ["ST-2874"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/ST-2874#problem:exact-tiflash-duplicate-registration-mechanism-not-applied"],
      "signalTextIncludesAny": ["task is already registered", "Failed to register MPP Task", "known duplicate MPP dispatch mechanism omitted"],
      "observedThrough": "2026-08-20",
      "effectiveAt": "2026-08-20T13:22:38Z",
      "verifiedAt": "2026-08-20T13:27:35Z",
      "attemptedAction": "Recall one exact-error TiFlash product topic and let the Scenario Router apply the known RPC-timeout-or-transient-network retry to duplicate-dispatch to duplicate-registration failure mechanism with a strict current-incident causality boundary and public Issue link.",
      "evidenceUrl": "https://tidb.atlassian.net/rest/api/3/issue/7946670/comment/23474317"
    }
  ]
}
-->

- Optimization ID: `tiflash-duplicate-mpp-dispatch-2026-08-20`
- Owner: Scenario Router repository product knowledge
- Source reference: `ST-2874` and `pingcap/tidb#65864`
- Implementation status: deployed to staging
- Effective status: `optimized_verified`

## Bounded problem

At the historical replay cutoff, `ST-2874` already contained the exact
`Failed to register MPP Task ... task is already registered` error. The current
Router response preserved duplicate registration and coordinator retry only as
unverified alternatives and did not apply the known public product mechanism.
The older live answer instead ranked unaligned apply and storage extrema.

The missing fact belongs to Router-selected product knowledge. It is not a
request for more customer context, a Provider acquisition gap, or a Final
Response wording problem.

## Candidate change

- Recall one topic only from the exact duplicate-registration error family.
- Explain the known TiDB retry, duplicate MPP dispatch, TiFlash duplicate
  registration response, and query-failure chain.
- Preserve that the incident's actual RPC timeout or network trigger remains
  unconfirmed without aligned evidence.
- Cite the public tracking issue without claiming a shipped fix or timeline.

## Verification status

Focused product-knowledge and optimization-record tests passed. The complete
repository suite passed 930 tests across 68 suites, and TypeScript typecheck
passed. A read-only offline real-model route simulation selected exactly
`tiflash-duplicate-mpp-task-dispatch` from an `ST-2874`-style exact error. A
generic TiFlash CPU plus unrelated Error 1105 input selects no topic.

Service PR
[`tidbcloud/aisupport#1043`](https://github.com/tidbcloud/aisupport/pull/1043)
merged as `3d3ad463bfdede4eaf45b01d87111a5b252dd6f0`. The staging deploy workflow
`32373381395` built that image, and
[`tidbcloud/app-delivery#77883`](https://github.com/tidbcloud/app-delivery/pull/77883)
merged the image tag. At 2026-08-20 13:22:38 UTC, the live Deployment and Ready
Pod both used `3d3ad463`; the Pod had zero restarts, both `/healthz` and
`/readyz` returned HTTP 200, and the runtime image contained the new topic.

Case-specific write replay `1f2d0846-518f-444c-bc98-65b7df02ab16` (DB run
`150113`) used the historical cutoff and explained the same known mechanism as
the human answer: RPC timeout or transient network trouble can cause TiDB to
retry the same MPP dispatch; TiFlash then returns `task is already registered`,
and TiDB may abort the query. It also preserved that the current incident's
actual network trigger was not proven and cited public Issue #65864.

The replay updated stable Jira internal comment `23474317` in place. Direct
readback returned that exact comment with `public=false` and the expected
mechanism and Issue link. DB readback showed one mapping under the historical
owner idempotency key, a succeeded run, and an `analyze_write` evaluation.

The system Judge recorded `not_comparable` because the result remains
`human_required`; it did not judge the answer worse. The bounded product-
knowledge criterion is verified by the case-specific output and Jira readback.

## Unresolved gaps

Clinic target resolution still failed for the three supplied cluster IDs, so
the same response retained a separate internal target-confirmation handoff.
That belongs to the target/context problem group and is not suppressed by this
exact product-knowledge record.

## Next validation action

Monitor later exact `task is already registered` cases for regressions where
generic resource evidence displaces the known mechanism or the current-
incident trigger is overstated as confirmed.