# Wetech Direct Cookie Query

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-direct-cookie-query-2026-08-03",
  "problems": [
    {
      "problemId": "wetech-query-range-browser-runtime-dependency",
      "summary": "Wetech Grafana query_range keeps a live Playwright browser for datasource discovery and metric requests after authentication, increasing CPU reservation pressure and provider bootstrap latency.",
      "status": "optimized_verified",
      "issueKeys": ["*"],
      "sourceRefs": [],
      "signalTextIncludesAny": ["browser-query-range", "diagnostic_auth_bootstrap_failed", "pod didn't trigger scale-up"],
      "observedThrough": "2026-08-03",
      "effectiveAt": "2026-08-03T15:30:49+08:00",
      "verifiedAt": "2026-08-03T15:45:11+08:00",
      "attemptedAction": "Export authenticated Wetech Grafana cookies and the P81-bound browser User-Agent to a private mode-0600 cache, execute datasource discovery and Prometheus query_range through direct HTTP, and launch Playwright only to refresh missing or rejected authentication before one direct retry.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/tree/main/auto-oncall-services/docs/opts/2026-08-03-wetech-direct-cookie-query.md"
    }
  ]
}
-->

- Optimization ID: `wetech-direct-cookie-query-2026-08-03`
- Owner: wetech-op-grafana / auto-oncall-services
- Source reference: recent optimizer scheduling and Wetech provider bootstrap investigation
- Implementation status: the skill and CPU request changes are deployed to
  staging and runtime-verified
- Effective status: `optimized_verified`

## Bounded problem

Wetech Grafana authentication requires the Perimeter81 browser flow, but the
existing metric command also keeps Playwright alive for datasource discovery
and the actual Prometheus request. That couples every metric query to browser
startup and adds avoidable CPU and timeout pressure.

## Candidate implementation

- Keep Playwright only for Perimeter81 and Grafana authentication.
- Export authenticated cookies and the P81-bound browser User-Agent into the
  skill-owned private cache with file mode `0600`; never write cookies to
  provider stdout or evidence artifacts.
- Use direct HTTP for datasource discovery, datasource-name resolution and
  `query_range`.
- Reuse valid cached cookies without importing Playwright. On authentication
  rejection, refresh once in the browser, close it, and retry direct HTTP once.
- Lower staging Deployment and Recent Optimizer CPU requests to one core while
  retaining two-core limits.

## Verification evidence

Contract tests cover cookie domain/path/expiry filtering, private cache
permissions, and the browser-free cached-session query path. All 35 skill tests
passed. In staging, the first `SaaS01` smoke authenticated and populated the
private session. A second bounded query executed with `python3 -S`, where
Playwright cannot be imported, and returned HTTP 200 with metric evidence. This
proves the cached query path is direct HTTP. The staging Deployment and Recent
Optimizer now render and run with request `1` / limit `2`. A temporary probe
using the optimizer's required hostname affinity, RWO PVC and exact resources
scheduled on the target node and reached Running. These checks are not a
case-specific replay.

## Unresolved gaps

- None for this bounded runtime optimization. It does not claim any change to
  diagnosis quality or case-level conclusions.

## Next validation action

Monitor the next scheduled optimizer run for normal scheduling and direct-query
reuse. A future runtime regression should create a new problem signal; no Jira
case replay or comment refresh is required for this operational change.