Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

kibana.request step fails with HTTP 500: {"api_keys":[]} when fetching an Agent Builder conversation — affects the published Root Cause Analysis template

Abierto
  • ¿Algo no está bien?
#75 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 4 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
48/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
javascript
Área
api, backend

Línea de trabajo

Start with root-cause-analysis.yaml and the kibana.request step type, then reproduce the GET /api/agent_builder/conversations/{conversation_id} call using the published Root Cause Analysis template. Trace how the request is authorized and why it returns {"api_keys":[]} despite a valid conversation_id. Done means the get_conversation step returns the full conversation object and the template can add its structured Case comment.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

The official "Root Cause Analysis (Agent Builder)" workflow template (root-cause-analysis.yaml, template slug root-cause-analysis, version 1.0.1) ships with a kibana.request step that fetches an Agent Builder conversation via GET /api/agent_builder/conversations/{conversation_id}. This step fails consistently with a 500 error, breaking the template as published.

Environment:

Elastic Cloud Serverless Observability project
Kibana 9.6.0
Agent Builder agent: default elastic-ai-agent

Steps to reproduce:

Install/create the Root Cause Analysis workflow (either via POST /api/workflows with the template YAML, or by hand through the Workflows UI — both produce the same result).
Trigger the workflow with a real alert as input (tested via the "Test Workflow" → Alert mode picker, selecting an existing ML anomaly-detection alert).
The rca_analysis step (Phase 1, ai.agent type) completes successfully and returns a conversation_id.
The get_conversation step (Phase 6, kibana.request type) runs GET /api/agent_builder/conversations/{{ steps.rca_analysis.output.conversation_id }} and fails.

Expected behavior:
The step should return the full conversation object (rounds/steps) so it can be summarized into a Case comment, per the template's documented purpose.

Actual behavior:

HTTP 500: {"statusCode":500,"error":"Internal Server Error","message":"{"api_keys":[]}"}

What we tried:

Recreating the entire workflow by hand through the Workflows UI (authenticated interactive session) instead of via the REST API, on the theory that some background actions need a Cloud API key binding that's only provisioned for UI-created objects (we've seen this exact pattern elsewhere — see below). This did not fix it — identical error both ways. This suggests the bug is in the kibana.request step type itself (or its authorization path) rather than being tied to how the workflow object was created.
Confirmed the conversation_id passed in is valid and non-empty (the prior step completes and returns it correctly).

Workaround:
Removed the get_conversation step and the dependent add_reasoning_to_case step (the structured "investigation steps" summary comment) from the workflow. The remaining add_rca_as_comment step, which posts the rca_analysis step's raw text output directly (no dependency on get_conversation), works fine. This means the template's core "investigate → file Case → attach raw analysis" flow works, but the structured, tool-call-by-tool-call summary comment described in the template's own documentation does not.

Related observation (may be the same root cause): we independently hit a similarly-shaped "Missing Elastic Cloud API Key" failure on ML anomaly-detection alert rules created via the Alerting REST API (xpack.ml.anomaly_detection_alert) — those were fixed by creating the rule through the UI instead of the API. Given get_conversation failed both ways, either this is a different underlying cause, or the UI-creation workaround doesn't propagate correctly to workflow steps that call back into other Kibana APIs (kibana.request) the way it does for native alerting rules.

Lenguaje dominante
JavaScript
Estrellas
60
Forks
38
Merge medio
3 d 9 h
PR fusionados (30 d)
11

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de elastic/workflows

Todos los issues de elastic/workflows

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.