我的incident已经自动变成resolved，但是触发workflow拿到的状态还是firing，请问为什么

[nsdsb123]

我的场景是这样的，我的告警alert和恢复alert具有相同的fingerprint，然后我配了workflow，当判断到是恢复的alert时，会将状态置为resolved，然后我针对同一个实例的alert，配置了Correlations，当一个实例出现多个alert会生成incident，然后当所有alert恢复的时候，我的incident会自动变成resolved状态，但是我的workflow，如下：
workflow:
id: dingtalk-incident-resolved
name: DingTalk Incident Resolved
description: Incident 恢复时发送钉钉通知
triggers:
- type: incident
events:
- updated
steps:
- name: format-incident-info
provider:
type: console
with:
message: |
Processing incident: {{ incident.user_generated_name }}
Status: {{ incident.status }}
Severity: {{ incident.severity }}
Alert Count: {{ incident.alerts_count }}

界面可以看到incident已经自动变成resolved状态，但是workflow获取到的状态还是firing，请问为什么

[dosubot[bot]]

@nsdsb123 这个问题是一个已知的时序/竞态条件问题。

从你的 workflow 配置来看，你使用的是 type: incident + events: updated 触发器，这应该能接收到正确的状态。但如果你的 Keep 版本较旧，incident 自动 resolve 时可能根本不会触发 workflow event，或者触发时传递的是旧状态。

关键修复：PR #5651 (2026年2月19日合并) 修复了 incident 自动 resolve 后不触发 workflow 或传递旧状态的问题 [1]。修复后，resolve_incident_if_require() 会在将状态更新并提交到数据库后，才发送 workflow event，确保 incident-triggered workflow 收到最新状态。

建议的排查步骤：

1. 确认你的 Keep 版本是否包含 PR fix: trigger workflows on auto-resolve of incidents #5651 的修复。如果版本较旧，升级应该能解决问题。

2. 如果版本已经是最新的，可以在 workflow 中添加一个 condition 过滤，确保只在 resolved 时执行：

triggers:
  - type: incident
    events:
      - updated
conditions:
  - type: threshold
    value: '{{ incident.status == "resolved" }}'

这样可以过滤掉 incident 更新过程中非 resolved 状态的中间事件（因为 incident 在 resolve 之前可能还有其他 update 事件被触发）。

3. 另外，如果你是通过 workflow 中 enrich_alert 来将 alert 置为 resolved 的，并且使用了 foreach 循环，请确认你的版本包含 PR #6213 的修复 [2]，该 PR 修复了通过 enrichment 解析 alert 时 incident 自动 resolve 检查被跳过的 bug。

简单来说：升级到最新版本应该能解决这个问题。如果已经是最新版本但问题仍然存在，可以分享一下你的 Keep 版本号，我可以进一步帮你排查。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[nsdsb123]

你好，我是用docker部署的，请问最新的镜像修复了这个问题了吗

[nsdsb123]

我已经按照你上面说的，更换成最新的镜像，但是会产生一个新问题，当我的incident自动变为resolved状态，现在不会自动触发下面的workflow，但是选中incident手动触发是可以正常工作的，为什么

workflow:
id: dingtalk-incident-resolved
name: DingTalk Incident Resolved
description: Incident 恢复时发送钉钉通知
triggers:
- type: incident
events:
- updated
steps:
- name: format-incident-info
provider:
type: console
with:
message: |
Processing incident: {{ incident.user_generated_name }}
Status: {{ incident.status }}
Severity: {{ incident.severity }}
Alert Count: {{ incident.alerts_count }}
- name: notify-incident-resolved
if: "'{{ incident.status }}' == 'IncidentStatus.RESOLVED'"
provider:
type: ssh
config: "{{ providers.test }}"
with:
command: |-
/home/developer/send_dingtalk_notification.sh << 'EOF'
OPERATION=resolved
INCIDENT_NAME={{ incident.user_generated_name }}
SEVERITY={{ incident.severity }}
INCIDENT_STATUS={{ incident.status }}
INCIDENT_ID={{ incident.id }}
ALERTS_COUNT={{ incident.alerts_count }}
ALERT_SOURCES={{ incident.alert_sources }}
SERVICES={{ incident.services }}
USER_SUMMARY={{ incident.user_summary }}
ALERT_NAMES={{#incident.alerts}}{{name}},{{/incident.alerts}}
EOF

[dosubot[bot]]

@nsdsb123 抱歉之前的写法有误。{{ providers.keep-api-key }} 确实不存在，Keep 的内部 API key 并不会自动暴露为 workflow 模板变量。

正确的做法是：通过 secrets 存储你的 API key，然后在 workflow 中引用。

1. 先获取你的 API Key：在 Keep UI 的 Settings 页面可以找到或生成 API Key。

2. 通过 API 为 workflow 写入 secret：

curl -X POST "http://keep-api:8080/api/workflows/{workflow_id}/secrets" \
  -H "Authorization: Bearer <你的token>" \
  -H "Content-Type: application/json" \
  -d '{"keep_api_token": "你的API Key"}'

[1]

3. 在 workflow 中使用：

steps:
  - name: get-resolved-incidents
    provider:
      type: http
      with:
        url: "http://keep-api:8080/api/incidents?status=resolved&limit=10"
        method: GET
        headers:
          X-API-KEY: "{{ secrets.keep_api_token }}"

认证使用 X-API-KEY header [2]。

注意：内置的 keep provider 只支持查询 alerts，不支持查询 incidents [3]，所以查询 incidents 必须用 HTTP provider 手动调 API。

如果你觉得这个 workaround 太复杂，建议还是等官方修复 incident auto-resolve 触发 workflow 的 bug，这样你就可以直接用原来的 type: incident 触发器了。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[nsdsb123]

workflow:
id: dingtalk-incident-resolved-workaround
name: 测试
description: 测试
triggers:
- type: manual
steps:
- name: get-incident
provider:
type: http
with:
url: "http://keep-backend:8080/incidents/47d6a8a8-b1be-4a1e-ad19-ae02151f8d70"
method: GET

workflow报错：2026-05-21T11:48:14.131000: Failed to run step get-incident with error 401 Client Error: Unauthorized for url: http://keep-backend:8080/incidents/47d6a8a8-b1be-4a1e-ad19-ae02151f8d70

[dosubot[bot]]

@nsdsb123 401 错误是因为缺少认证头。你可以使用 Keep 内置的 {{ env.KEEP_API_KEY }} 环境变量或者 workflow 自动生成的 API key。

另外你的 URL 路径也有问题，正确的 incidents 端点不带 /api/ 前缀。试试这样：

steps:
  - name: get-incident
    provider:
      type: http
      with:
        url: "http://keep-backend:8080/incidents/47d6a8a8-b1be-4a1e-ad19-ae02151f8d70"
        method: GET
        headers:
          X-API-KEY: "{{ env.KEEP_API_KEY }}"

如果 {{ env.KEEP_API_KEY }} 不起作用，你也可以在 Docker 部署中设置 KEEP_DEFAULT_API_KEYS 环境变量来创建一个默认的 API key，格式是 "name:role:secret"，例如：

KEEP_DEFAULT_API_KEYS=workflow-key:admin:my-secret-key-123

然后在 workflow 中直接用这个 key：

headers:
  X-API-KEY: "my-secret-key-123"

注意认证头必须是 X-API-KEY（大写，带连字符）[1]。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[nsdsb123]

workflow:
id: dingtalk-incident-resolved-workaround
name: 测试
description: 测试
triggers:
- type: manual
steps:
- name: get-incident
provider:
type: http
with:
url: "http://keep-backend:8080/incidents/47d6a8a8-b1be-4a1e-ad19-ae02151f8d70"
method: GET
headers:
X-API-KEY: "22e54afc-9ef3-422a-92ac-c70361e24a8"

我已经在settings设置了API keys，然后把这个值的放在workflow里面，但还是报错Failed to run step get-incident with error 401 Client Error: Unauthorized for url: http://keep-backend:8080/incidents/47d6a8a8-b1be-4a1e-ad19-ae02151f8d70
2026-05-21T13:03:31.368000: Error running workflow 1fc1811b-3dd3-4fe2-9d28-4d871866e4f6

[dosubot[bot]]

@nsdsb123 看了一下 Keep 的认证机制，有几个可能导致 401 的原因：

1. API Key 角色权限不足：访问 /incidents/{id} 需要 read:incident 权限 [1]。如果你创建 API key 时选择的角色是 Webhook（只有 write:alert 和 write:incident 权限），它没有 read:incident 权限 [2]。你需要创建一个 Admin 角色（拥有 read:*）或 Noc 角色（拥有 read:*）的 API key。

2. 确认 API key 值正确：Keep 使用 SHA-256 哈希来验证 API key [3]，API key 是在创建时一次性显示的 UUID 值。请确认你用的是创建时显示的原始值，不是数据库里的 hash 值。

3. URL 路径确认：/incidents/{id} 是正确的路径（没有 /api/ 前缀）[4]，这个你写的没问题。

建议：在 Settings → API Keys 中重新创建一个 Admin 角色的 API key，然后替换到 workflow 中试试。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.