Bug: Workflow_Runs query type consistently returns 0 rows when same URL+token directly returns data
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 52/100
Línea de trabajo
Traza la consulta Workflow_Runs desde su handler hasta pkg/github/client/client.go y compara después el filtrado temporal y el procesamiento de la respuesta con pkg/models/workflows.go y pkg/github/workflows.go, que están implicados por PR #526. Reproduce el marco vacío usando la consulta proporcionada y compara la solicitud construida con el curl correcto; se considera terminado cuando las ejecuciones conocidas rellenan los 14 campos para el intervalo seleccionado del dashboard.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Bug: Workflow_Runs query type returns 0 rows when the same URL+token directly returns the expected data
What you expected to happen
A Workflow_Runs query against a valid owner / repository / workflow should return the workflow runs visible to the configured credentials, like:
GET /repos/{owner}/{repo}/actions/workflows/{workflow}/runs?created=<from>..<to>
would return when called directly.
What actually happened
The plugin returns status: 200 with a valid frame schema (14 fields: id, name, head_branch, …) but all field value arrays are empty ([]). Other query types (Workflows, Issues, Pull_Requests, Repositories, Commits) against the same datasource work correctly and return populated data.
Steps to reproduce
-
Configure the datasource against an org with at least one repo and one workflow that has recent runs.
-
Add a panel with query:
{ "queryType": "Workflow_Runs", "options": { "owner": "<owner>", "repository": "<repo>", "workflow": "<workflow-file>.yml" } } -
Set the dashboard time range to a window that contains real runs.
-
Inspect the panel. The query returns no rows.
For reference, the same underlying API endpoint called directly with the exact created=<from>..<to> filter the plugin would construct (using either an App installation token or a PAT) returns the expected runs:
curl -H "Authorization: token $TOKEN" \
-H "Accept: application/vnd.github+json" \
"https://api.github.com/repos/<owner>/<repo>/actions/workflows/<workflow>.yml/runs?created=<from-iso>..<to-iso>&per_page=100"
# → total_count: 12, returns 12 runs
Query inspector evidence
Request body sent by the plugin (captured via Grafana's query inspector):
{
"queries": [{
"refId": "A",
"datasource": { "type": "grafana-github-datasource", "uid": "..." },
"queryType": "Workflow_Runs",
"options": {
"owner": "<owner>",
"repository": "<repo>",
"workflow": "<workflow>.yml"
},
"datasourceId": 62,
"intervalMs": 600000,
"maxDataPoints": 1180
}],
"from": "1781300092199",
"to": "1781904892199"
}
Plugin response:
{
"results": {
"A": {
"status": 200,
"frames": [{
"schema": {
"name": "workflow_run",
"fields": [
{ "name": "id", "type": "number", ... },
{ "name": "name", "type": "string", ... },
{ "name": "head_branch", ... },
{ "name": "head_sha", ... },
{ "name": "created_at", "type": "time", ... },
{ "name": "updated_at", ... },
{ "name": "run_started_at", ... },
{ "name": "html_url", ... },
{ "name": "url", ... },
{ "name": "status", ... },
{ "name": "conclusion", ... },
{ "name": "event", ... },
{ "name": "workflow_id", ... },
{ "name": "run_number", ... }
]
},
"data": { "values": [[], [], [], [], [], [], [], [], [], [], [], [], [], []] }
}]
}
}
}
Schema is correct; values are empty for every field.
What we ruled out during debugging
We spent a few hours narrowing this down. The matrix of combinations that all produced the same 0 rows result:
| Variable | Tested | Result |
|---|---|---|
| Plugin version | v2.3.0, v2.5.1, v2.6.0, v2.8.0 | All: 0 rows |
| Auth | GitHub App (ghinstallation) + Personal Access Token | Both: 0 rows |
Workflow workflow value |
basename (x.yml), numeric ID (<id>), full path (.github/workflows/x.yml) |
Basename and ID: 0 rows. Full path: workflow not found error (expected). |
| Workflow choice | several different workflows in the same repo | All: 0 rows |
| Repository choice | several different repos in the same org | All: 0 rows |
| Time range | now-7d, now-30d, explicit epoch ms covering known-good runs |
All: 0 rows |
| Direct API call with the same install token / PAT | Same URL the plugin would construct, same created=<from>..<to> filter |
Returns the expected runs (12 in our test) |
App permissions used (verified by minting an installation token via JWT and inspecting /app/installations/{id}/access_tokens response):
"permissions": {
"actions": "read",
"contents": "read",
"issues": "read",
"metadata": "read",
"pull_requests": "read"
}
repository_selection: "all".
Environment
- Grafana:
12.1.1 - Plugin: confirmed across
2.3.0,2.5.1,2.6.0,2.8.0 - Auth tested: GitHub App (with valid permissions including
actions: read) and Personal Access Token (withrepo, workflow, read:orgscopes) - Cluster: EKS, plugin running in the official Grafana Helm chart deployment
- Other query types from this plugin against the same datasource all work:
Workflows(lists workflows),Issues,Pull_Requests,Repositories,Commits
Possible related fix
PR #526 (fixes #503) addressed a similar "0 rows" problem in the Workflows query type — root cause was in pkg/models/workflows.go / pkg/github/workflows.go around CreatedAt/UpdatedAt time filtering with nil-handling and the addition of a None time field option.
Workflow_Runs does not expose a similar None option (the time filter is always applied based on the dashboard time range, constructed inside pkg/github/client/client.go as created=<from RFC3339>..<to RFC3339>). It's plausible the same underlying issue with time filter construction affects this query type but is not covered by #526's fix.
Hypothesis
The fact that:
- The plugin returns HTTP 200 (so the call to GitHub succeeded)
- The schema is fully populated (14 expected fields)
- Yet
data.valuesarrays are all empty - And a manual curl with the exact same URL+token returns runs
…suggests something between the GitHub response and the frame serialization is dropping rows. The fact that PR #526's fix on the Workflows query type added "improve time filtering logic with better nil handling" makes me suspect the same neighborhood — perhaps the response is being parsed and rows are filtered out by some predicate that shouldn't apply.
I'd be happy to add more diagnostic information (debug-level logs from the plugin, network trace) if useful — please indicate what would help most.
Workaround
For now we removed the Workflow_Runs-based panels from our dashboard and use only the query types that work (Workflows, Issues, Pull_Requests, Repositories). Workflow-run metrics remain unavailable to us via this plugin.
- Lenguaje dominante
- Go
- Estrellas
- 310
- Forks
- 70
- Merge medio
- 10 d 1 h
- PR fusionados (30 d)
- 1
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de grafana/github-datasource
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
grafana/github-datasource#796 · 2 comentarios ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 72/100
grafana/github-datasource#760 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
grafana/github-datasource#528 · 4 comentarios ·
-
Dependency DashboardAbierto
Dificultad 4/5 3-5 días Aptitud para principiantes 12/100
grafana/github-datasource#523 ·
-
prio/medium type/docs
Dificultad 3/5 1-2 días Aptitud para principiantes 30/100
grafana/github-datasource#509 ·
Todos los issues de grafana/github-datasource
Issues similares
-
area: global bug dx priority: low
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
grafana/mcp-grafana#1267 ·
Los mantenedores suelen responder en 1 día
-
automation models
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
coverage-gap good-first-pattern help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
GoogleCloudPlatform/k8s-aibom#114 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
txn2/mcp-data-platform#1984 ·
Los mantenedores suelen responder en 1 día