# Wetech Operation-Class Concurrency

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-operation-class-concurrency-2026-08-12",
  "problems": [
    {
      "problemId": "wetech-whole-batch-lock-consumes-scenario-budget",
      "summary": "Concurrent Wetech scenarios were forced through one whole-batch provider lock, so provider wait time consumed the scenario deadline before otherwise valid evidence could reach diagnosis.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29259"],
      "sourceRefs": [],
      "signalTextIncludesAny": ["Wetech whole-batch lock", "scenario deadline", "provider wait budget", "serialized provider batch"],
      "observedThrough": "2026-08-12",
      "effectiveAt": "2026-08-12T15:19:21Z",
      "verifiedAt": "2026-08-12T15:43:00Z",
      "attemptedAction": "Keep Wetech authentication serialized, replace whole-batch serialization with per-service-instance operation pools of five Metrics queries and two Dashboard queries, preserve declared metric-to-TopSQL dependencies, isolate the two Dashboard browser profiles, and serialize only shared metric-session refresh.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/tree/main/auto-oncall-services/docs/opts/2026-08-12-wetech-operation-class-concurrency.md"
    }
  ]
}
-->

- Owner: auto-oncall-services
- Source: APID-29259 replay `1824a3f4-00bc-4b0c-9eee-c46d7fbd1f39`
- Status: optimized_verified

The replay ran three scenario pipelines concurrently, but the runner held one
account-scoped Wetech lock around every complete provider batch. Later scenarios
spent their own 16-minute deadline waiting for earlier batches and timed out
despite the independent Metrics and Dashboard reads being safe to overlap.

This change keeps the stateful authentication boundary serialized. Provider
execution moves to two cross-process pools: Metrics has five slots and TiDB
Dashboard operations (TopSQL, Slow Query, and Statements) have two. Dashboard
slots use stable, separate Playwright profiles; normal metric reads continue by
direct HTTP with shared exported cookies, while browser-backed cookie refresh is
profile-locked. `instanceFromQueryId` remains an explicit dependency and cannot
start before its source metric completes. Manus remains serial.

Verification completed on staging image
`2b4b6564197d3409fb1207dc4b743390e095792a` with the Deployment fully observed,
Pod Ready with zero restarts, 2 GiB memory request and limit, and successful
health and readiness checks.

APID-29259 read replay `b0e1b36e-43f0-4a7e-9aa1-43c39e96163c` completed with
HTTP 200 in 621.8 seconds. Its two selected scenarios returned
`responseGeneration=complete` and `evidenceAcquisition=complete` with no failure
codes. Concurrent first-round provider batches completed in about 38 and 17
seconds; live memory was observed at about 1.1 GiB during provider execution.

Write replay `c5c3f32d-e039-4d09-89f4-82b5f1e87e61` selected three scenarios and
completed with HTTP 200 in 591.2 seconds, again with complete response and
evidence status and no failure codes. It updated existing Jira internal comment
`23323234`; exact-comment readback confirmed `public=false` and the expected new
body. Evaluation rated the refreshed answer `ai_better`. The replay did not
exhaust a scenario deadline or reproduce whole-batch provider-lock wait.