# Wetech Dolphinscheduler Target Inventory

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "wetech-dolphinscheduler-target-2026-08-14",
  "problems": [
    {
      "problemId": "wetech-dolphinscheduler-target-missing-before-auth",
      "summary": "APID-29343 named the dolphinscheduler OP cluster, but the region-scoped Wetech inventory had no matching canonical candidate, so three runs failed with diagnostic_wetech_target_missing before authentication.",
      "status": "optimized_unverified",
      "applicability": "Wetech OP diagnostic routing for the Asia production Dolphinscheduler cluster when ticket text uses its business name or known Aliyun full cluster name.",
      "issueKeys": ["APID-29343"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/APID-29343#problem:wetech-dolphinscheduler-target-missing"
      ],
      "signalTextIncludesAny": [
        "diagnostic_wetech_target_missing",
        "dolphinscheduler",
        "ali-sg-prod-saas-dba-dolphinscheduler-tidb"
      ],
      "observedThrough": "2026-08-14",
      "effectiveAt": "2026-08-14T01:21:59Z",
      "verifiedAt": null,
      "attemptedAction": "Add one asia-prod canonical Dolphinscheduler inventory entry with the customer-visible full name and the authenticated Grafana datasource name and UID; keep semantic selection in the Scenario Router and exact fail-closed validation in the runner.",
      "evidenceUrl": "https://github.com/tidbcloud/aisupport/tree/main/auto-oncall-services/docs/opts/2026-08-14-wetech-dolphinscheduler-target.md"
    }
  ]
}
-->

- Optimization ID: `wetech-dolphinscheduler-target-2026-08-14`
- Owner: Wetech target inventory
- Source reference: `APID-29343`
- Implementation status: merged and deployed to staging
- Effective status: `optimized_unverified`

## Bounded problem

APID-29343 identified the dolphinscheduler OP cluster, but the current
`asia-prod` Wetech inventory did not contain that business name or full cluster
name. The Scenario Router therefore had no authorized candidate to select and
three runs stopped with `diagnostic_wetech_target_missing` before Wetech
authentication began.

Authenticated Grafana datasource discovery returned the provider-owned name
`ali-sg-prod-game-dba-dophinscheduler-tidb` and UID `Fa6PfTaDk`. The spelling
and namespace differ from the customer-visible full name
`ali-sg-prod-saas-dba-dolphinscheduler-tidb`; both identify the same bounded
inventory target, without adding a Jira-ticket mapping to routing code.

## Candidate change

- Add `asia-prod/Dolphinscheduler` as the canonical target.
- Supply the customer-visible full cluster name as a known alias.
- Bind metrics transport to the exact authenticated Grafana datasource name
  and UID.
- Use the provider-owned name as the TiDB Dashboard proxy route only after a
  bounded probe reached that cluster's SQL sign-in page. Dashboard credential
  readiness remains an independent capability boundary.

## Verification evidence

PR [#901](https://github.com/tidbcloud/aisupport/pull/901) merged as
`e84fb16405b295d31d3284577e2b7fccb8f6a86d`. The staging delivery workflow
[31760133866](https://github.com/tidbcloud/aisupport/actions/runs/31760133866)
and app-delivery PR
[#77269](https://github.com/tidbcloud/app-delivery/pull/77269) completed. The
new Pod became Ready at `2026-08-14T01:21:59Z` with restart count zero, and its
bundled and installed Wetech inventory hashes matched.

A direct live query through canonical target `asia-prod/Dolphinscheduler`
completed with HTTP 200 against exact datasource UID `Fa6PfTaDk` and returned
ten historical `up` points. Historical APID-29343 read replay
`11f05f08-44fa-4b86-98d2-ea1f8d65677c` then selected that same canonical
target, completed auth bootstrap with `status=ready`, and acquired non-empty
TiKV CPU/quota evidence through `/api/datasources/proxy/uid/Fa6PfTaDk`.
The hottest TiKV CPU/quota series reached 93.57%; Scenario Diagnostic completed
without a failure code and Final Response returned `decision=internal_only`.
This passes the target-resolution and metrics acquisition criterion that the
three previous `diagnostic_wetech_target_missing` runs could not enter.

## Unresolved gaps

The target's Dashboard proxy route is established, but its SQL sign-in returns
`TiDB authentication failed`, consistent with the ticket's later report that
the standard monitor account and permissions had not yet been provisioned.
That is an expected external precondition, not a target-resolution, Grafana
Metrics authentication, or auto-oncall failure. Dashboard-dependent SQL
evidence remains unavailable until the user completes that setup.

The replay was read-only and its caller timed out before receiving HTTP headers
while the bounded Dashboard checks were still running; the runner continued and
materialized the complete final artifact. No Jira internal comment was
refreshed. The problem therefore remains `optimized_unverified` under the
case-refresh contract even though target resolution and metrics acquisition
passed.

## Next validation action

Refresh the applicable APID-29343 Jira internal comment through the authorized
write path, verify `public=false` and the stable mapping, then promote only this
target-resolution problem to `optimized_verified`. Track the standard account
as an expected provisioning state; it must not reopen the verified target
selection, be treated as another optimization problem, or be reported as an
authentication failure for Grafana metrics.