# Postmortem: TCOC-5870

> Workspace: `ws-1787726443146-f759396bc`
> Date: 2026-08-28
> Reviewer: evolver-bot

## Issue Summary

| Field | Value |
|-------|-------|
| Issue ID | TCOC-5870 |
| Alert Type | Changefeed stuck in "creating" state |
| Cluster ID | 10507906644386077751 |
| Cluster Type | essential (shared, ap-southeast-1) |
| TiDB Version | v8.5.3 |
| Time Window | 2026-08-26 04:45 UTC – ~07:00 UTC |

**Issue Description**: 两个 TiCDC changefeed（`cfd-f5pcctbgmjh77esiilom3ne7qu` 和 `cfd-4tspgxj7rrftzeldmsluzfcf4q`）长期卡在 "creating" 状态，根因为 Essential 集群 maxRCU 上限（50000）持续被 sysbench workload 打满，平台 provisioning gate 无法为 TiCDC 分配 K8s Pod。

## Actual Root Cause

> Human-confirmed root cause from user feedback (GitHub issue #1084/#1085) and in-workspace corrections.

Essential 集群（keyspace 237589 / `2yx9xETEut1LiMr`，`eddie-test-ess`）的 provisionedRCU 持续等于 maxRCU（30000 → 50000），ResourceLimitation 事件在建立 changefeed 前后已连续触发 3 次。平台 provisioning gate 在 provisionedRCU ≥ maxRCU 时阻断所有新 K8s Pod 分配（包括 TiCDC server pod），导致 changefeed 无限期停留在 "creating" 状态，manager 日志中整个时间窗内 0 次出现 "ticdc" 操作记录，即 TiCDC pod 从未被尝试建立。

## Agent Diagnosis Summary

**Turn 1（无引导诊断）**：Agent 读取 Jira 元数据和集群信息后，正确识别了 changefeed 卡在 "creating" 这一症状，并考虑了 ResourceLimitation 假设。然而 Agent 进入了错误方向：花费大量 tool call 搜索 TiCDC 容器日志（Loki logs）和 TiCDC 专有 metrics，而 TiCDC pod 根本从未被建立过，因此所有这些查询均返回空。最终输出"信心等级：低"，判断"无法验证（unverifiable）而非已排除"。

**Turn 2（用户介入）**：用户提示：(1) TiCDC K8s pod 根本没有被建立，应查 operation logs；(2) ResourceLimitation 可从 Event Center（Activity Hub）看到。这两条提示完全改变了搜索方向。

**Turn 3**：Agent 查询 Activity Hub，发现 3 次 ResourceLimitation 事件（时间线完整），查询 manager 日志确认 0 次 ticdc 操作，建立了完整因果链，结论正确。但当用户追问 `≥70000-100000` RCU 建议的依据时，Agent 坦承是"拍腦袋的"估算，未能从 provisioning gate 实际逻辑或 cdc-RCU 消耗精确推导，转而向用户询问"你知道具体检查什么条件吗？"。

## Scores

| Dimension | Score (1-5) | Notes |
|-----------|-------------|-------|
| Root Cause Accuracy | 3 | 最终结论正确，但 Turn 1 完全偏向错误方向，需用户纠正才到达正确路径 |
| Evidence Completeness | 3 | Activity Hub 事件和 manager logs 均已读取；TiCDC 侧无可观测数据（pod 未建立是已确认事实） |
| Causal Chain | 4 | Turn 3 因果链清晰：sysbench → RCU saturation → ResourceLimitation → provisioning gate 阻断 → TiCDC pod 未建立 → changefeed "creating" |
| Actionability | 3 | P1/P2/P3 建议层次清晰，但 RCU headroom 数字（≥70000-100000）依据不充分，被用户质疑后 Agent 无法解释 |
| Efficiency | 2 | 133 tool calls，1 次人工干预；Turn 1 大量浪费在无效的 TiCDC 日志/指标查询；正确路径（Activity Hub + operation logs）被用户提示后才找到 |
| **Overall** | **3.0** | |

## Human Guidance Log

### Intervention 1: 应查 operation logs 和 Activity Hub，而非 TiCDC 容器日志

- **Round**: #4（第 2 条用户消息）
- **User said**: "I'm pretty the K8s Pods for the TiCDC servers aren't even created. You should not search for TiCDC logs, instead search for operation logs. The ResourceLimitation event can be seen from Event Center."
- **Agent's mistake**: Agent 知道 ResourceLimitation 是重要假设，但选择通过 TiCDC 层（Loki container logs、TiCDC metrics）验证，而这些数据路径在 TiCDC pod 未建立时天然不可达。应先查 Activity Hub（Event Center）获取 ResourceLimitation 事件，再查 manager/operator 的 operation logs 确认 TiCDC pod 从未被调度。
- **Correct behavior**: 对于 Essential 集群 changefeed stuck-creating 场景：(1) 先查 Activity Hub 寻找 ResourceLimitation 事件；(2) 查 operation logs（manager 容器）确认是否有 TiCDC pod 创建操作；(3) 如 manager logs 中无 ticdc 操作且有 ResourceLimitation，直接判定为 provisioning gate 阻断。
- **Skill**: `tidb-clinic-diagnosis` / `tidb-perf-diagnosis`
- **Deficiency type**: FLOW

## Skill Deficiencies

### ISS-0126: Essential 集群 changefeed stuck-creating 应优先查 Activity Hub 和 operation logs，而非 TiCDC 容器日志

- **Type**: FLOW
- **Skill**: `tidb-clinic-diagnosis` / `tidb-perf-diagnosis`
- **Current behavior**: Agent 对 changefeed stuck-creating 症状，默认进入 TiCDC 容器日志 + 指标查询路径；对 Essential 集群，TiCDC pod 未建立时此路径天然返回空，浪费大量 tool call 后以"低信心"输出。
- **Expected behavior**: 对 Essential 集群 changefeed stuck-creating：首先查 Activity Hub 确认是否有 ResourceLimitation 事件；再查 manager/operator operation logs 验证 TiCDC pod 是否曾被调度。若 ResourceLimitation 已存在且 manager logs 中无 ticdc 操作，直接判定为平台 provisioning gate 阻断，不需要查 TiCDC 容器日志。
- **Suggested fix**: 在 SKILL.md CDC 诊断路由规则中增加：changefeed stuck-creating（非 stuck-running）→ 优先查 Activity Hub ResourceLimitation + manager operation logs，而非 TiCDC 容器日志/指标。
- **Priority**: P1-high
- **Status**: open

### ISS-0127: Agent 建议 RCU headroom 时需基于 provisioning gate 实际逻辑，而非拍脑袋估算

- **Type**: KNOWLEDGE
- **Skill**: `tidb-clinic-diagnosis`
- **Current behavior**: Agent 建议"提高 maxRCU 至 ≥70000-100000"，但该数字是 "2x headroom" 的保守估算，与 Essential tier TiCDC provisioning gate 的实际判断逻辑（是需要 N RCU 余量还是任何 RCU 余量即可）无关。用户追问时 Agent 无法解释，反而向用户询问 provisioning gate 的条件。
- **Expected behavior**: 建议 RCU headroom 前，先从 Activity Hub 事件或 API 文档获取 Essential tier TiCDC provisioning 对 RCU 余量的最低要求（如 cdc-RCU quota 所需的实际 RCU 单位数），基于实际数据给出建议值，而非泛化的 2x 估算。若数据无法获取，明确说明"无法精确估算，建议联系平台团队确认"，而非向用户询问平台内部逻辑。
- **Suggested fix**: 在 SKILL.md 的 ResourceLimitation 处理规则中补充：建议 maxRCU 调整量时，需引用 cdc-RCU 配置值（可从 changefeed 配置或集群 API 获取），若 cdc-RCU=1，则只需 provisionedRCU + 1 < maxRCU 即可解除阻断，而非 2x headroom。
- **Priority**: P2-medium
- **Status**: open

## Key Queries

### Activity Hub ResourceLimitation 事件查询

```bash
python3 .opencode/skills/builtin/clinic-cli/scripts/clinic_cli.py activity-events \
  --cluster-id 10507906644386077751 \
  --start 1753502400 --end 1753516800 \
  --event-type ResourceLimitation \
  --output /path/to/evidences/events.json
```

### Manager operation logs（确认 TiCDC pod 是否被调度）

```bash
python3 .opencode/skills/builtin/clinic-cli/scripts/clinic_cli.py logs \
  --cluster-id 10507906644386077751 \
  --container manager \
  --start 1753502400 --end 1753516800 \
  --query "ticdc"
```

## Lessons Learned

- **Essential 集群 changefeed stuck-creating 的正确诊断路径是 Activity Hub + operation logs，而非 TiCDC 容器日志**：TiCDC pod 未建立时，所有 TiCDC 层的可观测数据都不可达，这是平台架构特性而非工具故障。
- **ResourceLimitation 是 Essential 集群 TiCDC provisioning 的关键守门条件**：provisionedRCU ≥ maxRCU 时，平台 provisioning gate 不分配任何新 pod，包括 TiCDC server pod。
- **TCOC-5870 是 TCOC-5841 TiCDC 诊断系列的延续，但根因不同**：TCOC-5841 是 Essential 层 TiCDC noisy-neighbor（changefeed 卡在 running/lag），本案是 Essential 层 provisioning gate（changefeed 卡在 creating）。两者都需要超出 TiCDC 容器日志的观测路径。
- **RCU 建议值应基于 provisioning gate 实际逻辑**：对 Essential 集群，只需 provisionedRCU 降至 maxRCU 以下（哪怕 1 RCU 余量）即可解除阻断，不需要大幅提高 maxRCU。