# Wetech metrics and Dashboard API session reuse Owner: Wetech Managed Tool Provider Executor, `index.mjs`. Source: the user's API-first request following two Grafana login failures in APID-29464 replay `8d2b9f6c-0d4e-4e93-81eb-e17bb6530f84`. Repair base: `f22d9a2666c74a5f8a30539557ccbb8c284a8e55` from freshly fetched `origin/main`. Released in Wetech v53 through PR #1387 (merged `3cddb9df6075260f77d4087ad72e6ddd637e851d`). The initial HTTP probe uses cached cookies and their authenticated User-Agent. Dashboard adds the token stored under the selected origin and cluster. A ready session performs all metrics, TopSQL, Statements, Slow Query and selected plan API requests without launching a browser. API requests do not follow redirects with Dashboard authorization headers. HTTP 401, an authentication redirect, or a missing Dashboard token enters the existing bounded login flow. Permission errors, rate limits, server errors and network failures do not initiate login. Legacy states without a User-Agent learn the native pinned browser identity once without UI navigation, then persist it for subsequent HTTP-only calls. Actual browser login retains native headful Chromium identity. Application launch matching excludes support widgets such as Open Intercom Messenger. A launch click timeout or ERR_ABORTED yields to the next API probe within the existing deadline. Each login loop attempts that launch once. Dashboard navigation ERR_ABORTED also returns to readiness checking; unrelated navigation errors remain errors. Successful stderr diagnostics record HTTP transport, browser startup and login actions without adding them to evidence. Verification is recorded under the private local directory `~/.cache/auto-oncall-services/investigations/wetech-api-first-20260907/`. The blocking criterion is real metrics and Dashboard data with `browserStarted=false` on cached sessions, plus one controlled empty-state login. Tests cover the production execute function with deterministic HTTP and browser responses, including authentication recovery and ordinary errors. Real source checks use the previously authorized temporary E2B fallback with Playwright 1.61.1, native Chromium, the production entrypoint and stdin, local private state persistence, and public inbound traffic disabled. Docker cannot start on this host (`spawn docker ENOENT` and no Docker Desktop daemon), so these are E2B source tests, not a local Docker pass, Agent9 installation proof, or a full ticket replay. Source validation completed on 2026-09-07: - Full `npm test`: 1,158 service tests and six isolated-runner tests passed. - Metrics cached session: 3,270 ms, one series and six points, no browser. - Dashboard cached session: 4,363 ms, three Slow Query rows, no browser. - Empty-state metrics: 18,627 ms, P81 password/MFA and Grafana login completed, one series and six points. - Dashboard without a token after that bootstrap: 19,184 ms, Dashboard login completed and three Slow Query rows returned. - Tests used yk-qfxt / asia-prod, a five-minute window, `vector(1)` or Slow Query limit 3. The temporary E2B sandbox was deleted successfully. These E2B experiments verified the API path and login recovery. Final review also preserved provider-session failure scope for the new API probe stage and ensured that a not-yet-rendered application button does not consume the one click attempt; final source has the complete passing offline regression. The immutable candidate package and bundle were prepared in S3 and pinned in the worktree, without changing any live ConfigMap, Pod, installation or Agent. Package digest: `cf3ee14aeace1d97ba431d0c29473a9d40c635d83031d609fc1da6bcd016e54a`. Bundle digest: `3e879b420a5785a2d8e2ffce3155ebee7f4b937bcc64827664168d7c74c883c6`. Remaining validation: cross-sandbox reuse of P81 application authorization. The installation and post-deployment canary are recorded below. This record does not resolve or suppress SQL workload attribution, TopSQL comparison coverage, or diagnosis quality. Deployment verification on 2026-09-07: - CI passed on rerun after one existing 10 ms concurrency-overlap assertion failed. The runner and that test were unchanged; this repair did not weaken the assertion. - AOS release run 34124946416 succeeded. App-delivery PRs #79450 and #79451 merged. The Ready Pod reported build SHA `3cddb9df6075260f77d4087ad72e6ddd637e851d` and image digest `sha256:a07246e45c6d01e106bb0ce01f0d9b48c52125342f32ff296836078b1b5f39bb`. - Agent9 loaded the pinned bundle on both Ready replicas without an image change. Evidence Agent installation readback matched Wetech v53 and its exact package digest. One real Managed Tool canary, operation `op_d3f34cdb345547be89209f3a5db94cdb`, returned one series and six points. - The user explicitly waived additional Docker validation for this release. - Full read replay started as isolated Job `aos-replay-apid-29464-d9dc07d5`, run `aea15dd8-c525-4bf9-9891-5470d8359302`, pinned to the verified AOS digest. While it was running, the independent TopSQL/HTTP diagnostics release #1388 started; exact per-operation Managed Tool versions must be inspected. Full replay completed successfully in 1,086,990 ms (18m 6.990s). The read run fingerprint is `c30d445686995a491a138205f50ccb49acd7de4bcd4b09435ab41a4913cd8dec`. Judge returned `ai_better`, with no AI gaps, and the answer agreed with the human's appropriate-index/plan and mixed-workload-pressure conclusion. No Jira, DB or Base publication was requested or performed. The Job was exported and deleted. The original operation traces contain 22 successful Managed Tool executions: seven metrics, nine TopSQL and six Slow Query calls. All actually used Wetech v54 (`eecc16ae2f187145db39fbf048ba678779ed22e355b076b336ee4676c8e1b00b`), which contains this API-first repair plus the independent #1388 change. The isolated AOS image remained `3cddb9df`; do not call this an exact v53-only full replay or a replay of the later AOS image. No login/navigation failure occurred. One metric returned no series. The top-level `providerQueryAttempts` projection contains only one entry, so the count above is verified from raw Managed Tool operations, not inferred from that incomplete projection; preserving the attempt ledger is a separate issue. The 22 matching runtime stderr records all show `browserStarted=true` and `cached_api_session_auth_required`, followed by successful HTTP data queries. The deployed conditional API-first path works, but live cross-sandbox cache reuse has not met this record's browser-free criterion. Keep the problem at `optimized_unverified` rather than claiming that Managed Tool calls now avoid UI in production. A bounded follow-up using two temporary E2B sandboxes reproduced the boundary: API `/api/user` returned 200 in sandbox A without browser startup; the exact saved cookie/User-Agent state copied to sandbox B returned 307 to P81 `/connect`; after B's successful authorization, A still returned 200 with its original state. Cookies and User-Agent alone are therefore insufficient to reuse that P81 application authorization across these sandboxes. The precise server-side binding (for example network identity) was not established. Both sandbox checks used the same Playwright 1.61.1 template and the same bounded `vector(1)` request. The source was instrumented only to log the readiness probe, without another code release. Next action: investigate the P81 application-authorization boundary across Managed Tool sandbox executions before selecting a further transport or lifecycle repair. Do not add speculative retries or classify the valid-cookie case as proven on every fresh production sandbox. Preserve the successful 22-query replay and its independent Judge result.