# Wetech Exact Write Transaction Facts

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-exact-write-transaction-facts-2026-08-18",
  "problems": [
    {
      "problemId": "exact-write-digest-collapsed-to-topsql-without-transaction-facts",
      "summary": "The Evidence Agent planned only cluster-level TopSQL for a Wetech write-path scenario despite an exact supplied DELETE Digest, so no per-execution write transaction query reached the Provider Executor.",
      "status": "optimized_verified",
      "applicability": "Wetech write-path-contention diagnostics with exactly one customer-supplied SQL Digest and retained Slow Query executions.",
      "issueKeys": ["APID-29340"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/APID-29340#problem:exact-write-transaction-facts-not-acquired"],
      "signalTextIncludesAny": ["exact supplied DELETE Digest", "write-path only retained TopSQL", "transaction fields missing"],
      "observedThrough": "2026-08-18",
      "effectiveAt": "2026-08-18T09:38:47Z",
      "verifiedAt": "2026-08-18T10:42:17Z",
      "attemptedAction": "Make exact-Digest Slow Query the primary Wetech write-path surface and require bounded transaction size, write-response stage, retry, lock, local-latch, resolve-lock, backoff, and scan discriminators before optional TopSQL.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/pull/981"
    }
  ]
}
-->

- Optimization ID: `wetech-exact-write-transaction-facts-2026-08-18`
- Owner: Evidence Agent planning contract for Wetech `write-path-contention`
- Source reference: `APID-29340`, replay
  `2be0f96f-099a-419e-952e-fdef7fbed336`
- Implementation status: merged in PR `#981` and deployed as `8291d520`
- Effective status: `optimized_verified`

## Bounded problem

After the target, Digest, and historical time window were corrected, Wetech
returned seven exact Slow Query executions. The query-latency branch preserved
scan and latency facts, but the write-path branch retained only one TopSQL
query. The final answer therefore quantified scan amplification but omitted the
provider-supported `write_keys`, `write_size`, write-response stage, retry,
lock, local-latch, resolve-lock, and backoff fields needed to explain the write
transaction and compare it with the 0.73-second aligned execution.

## Change

- Apply the exact supplied Digest rule to `write-path-contention`, not only
  query-latency/query-execution.
- Make exact-Digest Slow Query the primary per-execution surface for that
  branch, before optional cluster-level TopSQL.
- Tell the Evidence Agent which supported write/transaction discriminators to
  select while retaining the existing 12-field bound.
- Preserve the semantic boundary: `write_keys` measures written keys and must
  not be presented as affected rows.

## Verification status

The deployed source-case read replay
`368bc618-2a66-4d42-be2b-737ad14c584f` selected exact-Digest Slow Query as the
primary write-path surface and carried the requested transaction facts into
diagnosis. The final write replay
`dcd62c16-f47b-42db-bcb4-4d252d413a8e` reproduced that path on live image
`5b2c2addc361b8528e1a2a4d4f324ce9c5f37226`, persisted run `150086`, and
updated the stable internal Jira comment `23548869` in place with
`public=false`. The Base row synced at `2026-08-18T10:42:17Z`, so this problem
is `optimized_verified`.

## Unresolved gaps

Wetech Slow Query still does not expose a trustworthy affected-row count;
`write_keys` cannot replace that fact. The deployed diagnosis therefore keeps
actual affected rows and the exact index-maintenance split unresolved rather
than inferring either from the roughly 7.26 million written keys.

## Next validation

Monitor future exact-Digest write-path cases for regressions in per-execution
transaction-field acquisition. Treat missing affected-row or structured-plan
facts as separate provider-capability gaps, not a reason to repeat this action.