「假健康」故障：Incident Agent 依赖过期缓存导致误判

Summer Bug Smash: Clear the Lineup 🐛🛹

这是向 DEV 组织的 Summer Bug Smash: Clear the Lineup（由 Sentry 驱动）提交的作品。

管道是健康的。

至少，我的 incident agent 是这么告诉我的。

但有一个问题：它看不到实时的 Fivetran 管道。

实时检查失败了，所以应用回退到了缓存的证据。那份快照仍然显示 connected 和 on_schedule。

最终的判决仍然是：

请求成功了。

回退数据看起来是健康的。

但结论仍然是错误的。

应用将最后已知的状态悄悄地当成了当前状态。

这就是"虚假的绿色"。

当前的置信度需要当前的证据。

Pipeline Rescue Agent 是一个 Next.js incident 调查应用，它结合 connector 健康状态和数据新鲜度信号来决定哪些还需要调查。

Gemini 在恢复规划流程的后期运行。"虚假绿色"判决发生在确定性应用逻辑中，在模型介入之前。

这个决策点的问题很简单：

这条管道现在健康吗？

我发现了一个应用比其证据所允许的更有信心的情况。

Bug Fix or Performance Improvement

当实时 Fivetran 遥测数据不可用时，Pipeline Rescue Agent 回退到了缓存的 connector 证据。

我想保留这个回退机制。最后已知的 connector 状态在 incident 期间仍然有用。

失败的实时路径是触发条件。

它不是应用缺陷。

真正的缺陷发生在之后：缓存的证据仍然被允许支持当前的 Healthy 判决。

修复之前，决策状态是这样的：

evidence.mode = cached_fivetran_evidence
evidence.live = false

fivetran.mcp_ok = false
fivetran.setup_state = connected
fivetran.update_state = on_schedule

pipeline.health_verdict = healthy
false_green.detected = true

在这个调查中，有三种故意的仓库状态：

序列是经过精心设计的：

reproduce
→ instrument the still-broken decision
→ inspect
→ diagnose
→ fix
→ verify

修复前的 Sentry 决策跨度：缓存的、非实时的证据仍然生成了 Healthy 判决。

几乎每个单独的状态值看起来都是合理的。

/api/investigate 请求本身成功完成了。回退返回了数据。缓存的 connector 状态显示 connected 和 on_schedule。没有活动中的警告或任务。

端点成功完成；语义层面的失败本身没有抛出异常。

只有当证据来源和最终决策被一起检查时，矛盾才显现出来：

cached evidence
+ live = false
+ MCP unavailable
→ Healthy

缓存本身在履行它的职责。

健康门控在要求缓存证明它无法证明的东西。

缓存的证据可以回答：

这条管道现在健康吗？

Healthy 不仅仅是一个显示的状态。

connector 决策会影响 agent 最终的 pipelineStatus，getLikelyIssue 会用它来决定下一步应该检查什么。

当无法确定 connector 健康状态时：

Needs review
→ likely issue: Connector health

当 connector 被认为是健康的，但目标数据是过期的：

Healthy + stale data
→ likely issue: Upstream source freshness

虚假的绿色不仅仅改变了显示的状态；它可能改变下一步调查检查的内容。

我不需要应用假设 Fivetran 坏了。我需要它在当前 connector 证据不可用时停止清除 connector 健康状态。

Sentry 暴露了矛盾

我首先通过 /api/investigate 重现了这个可疑的 Healthy 结果。

在修复之前，我添加了一个自定义的 Sentry pipeline.decision 跨度，包含该决策背后的运行时状态：

evidence.mode
evidence.live
fivetran.mcp_ok
fivetran.setup_state
fivetran.update_state
pipeline.health_verdict
false_green.detected

这是一个静默的正确性 bug。

请求工作了。回退工作了。值看起来合理。失败在于从它们得出的结论。

Sentry 将看起来健康的状态内容、其非实时的来源和最终判决放在了同一个追踪中。

这将调试问题从：

为什么这个端点返回 Healthy？

改变为：

为什么允许非实时证据支持 Healthy？

Seer 与根因分析

我使用 Seer 分析了捕获到的失败追踪。

它将证据时效性标记为可能缺失的决策约束：看起来健康的缓存值进入了一个没有强制执行实时来源的判决路径。

Seer RCA：失败的追踪指向证据时效性/来源作为缺失的决策约束。

我将其作为假设，并在源代码中验证。

我也没有字面地复制生成的建议。

Pipeline Rescue Agent 支持两条合法的实时证据路径：

mcp_live
live

当 MCP 路径不可用时，直接的实时 Fivetran API 响应仍然可以是当前的证据。

所以正确的约束不是：

Healthy 需要 MCP 成功

而是：

Healthy 需要实时证据

缺失的不变量

这个 bug 归结为一个安全属性：

Healthy 判决需要实时证据。

Healthy ⇒ evidence.live = true

失败的 Sentry 追踪违反了这一约束：

evidence.live = false
pipeline.health_verdict = healthy

缓存可以保留；只需要改变决策边界。

PR: Fix false-green pipeline health verdicts from cached Fivetran evidence

我在一个被生产路由使用的小型辅助函数中隔离了健康决策：

export function evaluateFivetranHealth({
  mode,
  setupState,
  updateState,
  hasWarnings,
  hasTasks,
  paused,
}) {
  const hasLiveEvidence = mode === "mcp_live" || mode === "live";

  const isHealthy =
    hasLiveEvidence &&
    setupState === "connected" &&
    updateState === "on_schedule" &&
    !hasWarnings &&
    !hasTasks &&
    paused === false;

  return {
    hasLiveEvidence,
    isHealthy,
  };
}

重要的区别很小：

历史证据仍然可以指导调查。

只有当前证据才能证明当前的健康状态。

我检查了周围的调查流程是否存在相同的来源假设。缓存的 Fivetran 证据不再作为成功的当前 connector 检查出现，不再算作实时证据，也不再在恢复推理中被描述为代表当前健康。生产规则现在存在于上面那个小的纯辅助函数中，这也使决策边界可以直接测试。

修复后：相同的非实时证据类别，更安全的决策

来 commit b05d2cccf93713f6a52a4a4ec6fa6b1600cbec86 的最终 Sentry 追踪显示：

evidence.mode = cached_fivetran_evidence
evidence.live = false

fivetran.mcp_ok = false
fivetran.setup_state = connected
fivetran.update_state = on_schedule

provenance.guard_applied = true
pipeline.health_verdict = needs_review

最终的 Sentry 决策跨度：相同的非实时证据类别现在产生 Needs review。

状态值仍然表面上看起来健康。

实时遥测仍然不可用。

修复并没有使不可用的遥测变得可用。它改变了应用从这个不确定性中可以得出什么结论。

cached + non-live
→ Needs review

历史 RED → 最终 GREEN

我想要比以下更强的验证：

打补丁后的应用通过了补丁后编写的测试。

所以我将决定性的断言移到了仓库外部，针对标记的历史应用和最终分支运行，且未做更改。

该脚本不导入任何应用决策逻辑。它故意只读取两个版本中都可用的响应字段：

timeline[].evidence.mode
agentRun.decision.pipelineStatus

如果未重现预期的缓存回退条件，它也拒绝计算运行次数。

简化的形式，外部断言强制执行了三个条件：

if (mode !== "cached_fivetran_evidence") {
  throw new Error("TEST INVALID: cached fallback was not reproduced");
}

if (verdict === "Healthy") {
  process.exit(1);
}

if (verdict !== "Needs review") {
  throw new Error(`Unexpected verdict: ${verdict}`);
}

我针对历史基线运行了相同的外部断言：

Commit:
6194a3b14efd33a0d5f8235f703187005123a0f9

Evidence mode:
cached_fivetran_evidence

Pipeline verdict:
Healthy

Result:
FAIL

Exit code:
1

然后针对最终分支运行：

Commit:
b05d2cccf93713f6a52a4a4ec6fa6b1600cbec86

Evidence mode:
cached_fivetran_evidence

Pipeline verdict:
Needs review

Result:
PASS

Exit code:
0

外部黑盒检查：历史基线失败；最终分支通过。

这个比较并不是声称两次执行之间每个低级别原因都相同。

那不是这个断言要测试的内容。

受控的应用条件是：

Fivetran 证据是缓存的而不是实时的。

该证据还能证明当前的健康状态吗？

历史应用：

决策边界正向控制

还有一个坏的修复我想排除：

如果 Healthy просто变成不可能了怎么办？

由生产路由导入的相同纯谓词在边界两侧都被检查：

这是一个故意设计的决策边界检查。

它不声称联系实时 MCP 服务器或实时 Fivetran API。

它的目的更窄：两种支持的实时证据模式仍然有资格获得 Healthy，而缓存证据则没有。

非实时应用行为通过 /api/investigate 和外部黑盒断言单独验证。

最终分支验证：

npm run test:health-invariant
PASS

PIPELINE_RESCUE_URL=http://localhost:3001 npm run test:false-green
PASS

External black-box check
PASS
exit 0

npm run lint
PASS

npm run build
PASS

HTTP 回归检查确认：

Evidence mode: cached_fivetran_evidence
Live evidence: false
Pipeline verdict: Needs review

PASS: non-live cached evidence cannot produce a Healthy verdict.

这正是 Sentry 发挥作用的地方：/api/investigate 成功完成，所以普通错误监控没有暴露语义层面的失败。

pipeline.decision 跨度使来源、活性、connector 状态和最终判决在那个成功的请求中同时可观测。

Sentry 不仅仅是在事后验证修复：我从仍有 bug 的版本中捕获了矛盾，用那个失败的追踪作为 Seer 的运行时上下文，然后在修复后再次检查了相同的决策。

Seer 然后帮助将那个运行时矛盾缩小到证据时效性，我在实现更窄的应用约束之前针对源代码进行了验证。

修复后，最终追踪显示：

evidence.live = false
provenance.guard_applied = true
pipeline.health_verdict = needs_review

Sentry 没有取代调试。

它暴露了普通成功/失败监控无法解释的隐藏决策状态。

修复前

没有实时 Fivetran 遥测
→ 缓存的看起来健康的证据
→ Healthy

修复后

没有实时 Fivetran 遥测
→ 缓存的证据保留为上下文
→ 实时证据守卫
→ Needs review

缓存仍然可以告诉调查者最后已知的情况。

只是不再有资格回答：

这条管道现在健康吗？

当前的置信度需要当前的证据。

PR: github.com/mneang/pipeline-rescue-agent/pull/1