# Expected Diagnosis: TCOC-5870

## Root Cause

Essential 集群（keyspace 237589，`eddie-test-ess`，ap-southeast-1）的 provisionedRCU 持续等于 maxRCU（50000 RCU），触发 ResourceLimitation 事件。平台 provisioning gate 在 RCU 上限时阻断所有新 K8s Pod 分配，TiCDC server pod 从未被建立，导致 changefeed 无限期停留在 "creating" 状态。

## Evidence Chain

1. **Activity Hub**：在 changefeed 建立前后触发 3 次 ResourceLimitation 事件（02:58、03:58、04:58 UTC），均为 provisionedRCU=maxRCU=50000
2. **Manager operation logs**：整个时间窗内（04:45–07:00 UTC）manager 日志 0 次提到 "ticdc"，即平台从未尝试建立 TiCDC pod
3. **事件时间线**：eddie.jiang 在 03:43 UTC 将 maxRCU 30000→50000，但 sysbench workload 立即将新上限也打满；changefeed 建立于 04:45 UTC（ResourceLimitation 已存在）

## Causality

sysbench workload 持续消耗全部 50000 RCU
  → provisionedRCU = maxRCU = 50000（ResourceLimitation 触发）
  → Essential 平台 provisioning gate 判定无可用 RCU 配额
  → TiCDC K8s Pod 建立请求被阻断（manager logs 中 0 次 ticdc 操作）
  → Changefeed 无限期停留在 "creating" 状态

## Severity

Medium（集群为 `eddie-test-ess` 测试环境，sysbench 测试负载，非生产数据）

## Recommendations

1. **P1 立即**：确保 provisionedRCU < maxRCU（哪怕 1 RCU 余量）——停止/降低 sysbench workload，或提高 maxRCU 使其超过当前消耗峰值
2. **P1 立即**：删除两个卡住的 changefeed，RCU 有余量后再重建
3. **P2 预防**：Console/API 在 ResourceLimitation 阻断 changefeed 建立时应返回明确错误（如 "insufficient RCU capacity"），而非无限等待
4. **P3 追蹤**：确认 sysbench workload 是否为必要测试负载——若是临时压测，压测结束后 RCU 恢复正常即可自动解除

## Scoring Rubric

> Checklist for regression testing. The Agent must satisfy these to pass.

- [ ] 识别 changefeed 卡在 "creating" 状态（非 running/error 状态）
- [ ] 查询 Activity Hub 并发现 ResourceLimitation 事件（≥1 次）
- [ ] 确认 ResourceLimitation 发生时间早于或接近 changefeed 建立时间（04:45 UTC）
- [ ] 查询 manager/operation logs 并确认 TiCDC pod 从未被建立（0 次 "ticdc" 操作）
- [ ] 正确建立因果链：provisionedRCU=maxRCU → provisioning gate 阻断 → TiCDC pod 未建立 → changefeed stuck creating
- [ ] 给出解法：降低 workload 或提高 maxRCU 使 provisionedRCU < maxRCU
- [ ] 不在 TiCDC 容器日志/指标上浪费大量 tool call（TiCDC pod 未建立时这些路径无效）