# Wetech Auth Bootstrap Headroom

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-auth-bootstrap-headroom-2026-08-05",
  "problems": [
    {
      "problemId": "wetech-auth-bootstrap-nearly-exhausts-outer-stage-cap",
      "summary": "A successful Wetech bootstrap consumed 119.4 seconds under a 120-second outer stage cap, leaving insufficient structured-return and cleanup headroom even though the provider readiness probe has its own bounded limit.",
      "status": "optimized_verified",
      "issueKeys": ["APID-29231"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29231#problem:wetech-auth-bootstrap-headroom"
      ],
      "signalTextIncludesAny": [
        "diagnostic auth bootstrap consumes 119 seconds",
        "auth bootstrap outer stage cap is 120 seconds",
        "structured auth result has no cleanup headroom"
      ],
      "observedThrough": "2026-08-05",
      "effectiveAt": "2026-08-05T13:44:30Z",
      "verifiedAt": "2026-08-05T13:57:34Z",
      "attemptedAction": "Raise only the outer Wetech diagnostic auth-bootstrap stage cap from 120 seconds to 150 seconds while preserving the provider readiness-command cap, the shared 20-minute diagnostic pipeline deadline, and downstream reserves.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/APID-29231#comment-23279460"
    }
  ]
}
-->

- Optimization ID: `wetech-auth-bootstrap-headroom-2026-08-05`
- Owner: auto-oncall-services
- Source reference: `APID-29231` replay
- Implementation status: merged and deployed to staging
- Effective status: `optimized_verified`

## Bounded problem

The prior successful Wetech auth bootstrap consumed 119.403 seconds under a
120-second outer stage cap. The stage therefore had almost no margin for model
preparation, the single provider readiness command, structured return, and
stream cleanup.

## Implementation

Raise `AUTO_ONCALL_DIAGNOSTIC_AUTH_TIMEOUT_MS` and its code default from
120,000 to 150,000 milliseconds. Keep the provider readiness command at its
existing 120-second limit. Do not raise the shared 20-minute pipeline deadline,
worker timeout, scenario timeout, or provider-query subdeadline.

## Verification

- Local timeout and deployment-contract tests pass.
- Source PR `tidbcloud/aisupport#636` and staging app-delivery PRs `#76341` and
  `#76342` are merged.
- The live staging pod started at `2026-08-05T13:44:30Z` with
  `AUTO_ONCALL_DIAGNOSTIC_AUTH_TIMEOUT_MS=150000`, while the pipeline and worker
  limits remained 1,200,000 and 1,500,000 milliseconds.
- The same-cutoff `APID-29231` write replay
  `1208ef89-9474-4024-a3a2-a5f0faccba89` completed auth successfully in
  115.798 seconds, leaving 34.202 seconds of outer-stage headroom. Evidence
  acquisition and publication both completed, DB run `120023` succeeded, and
  the existing Jira internal comment `23279460` was updated with
  `public=false`.

## Unresolved gaps

- This quota change removes the near-edge failure risk but does not itself make
  authentication faster.
- The verified run still called `list_clusters` three times before one
  `datasources` lookup. Eliminating duplicate model-driven target discovery is
  a separate potential latency optimization and is not claimed by this record.

## Next validation action

Evaluate a deterministic Wetech auth/bootstrap helper separately; preserve the
real provider readiness probe and measure whether duplicate target discovery
can be removed without changing provider isolation.