Bug: Workflow_Runs query type consistently returns 0 rows when same URL+token directly returns data
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 52/100
Hướng nghiên cứu
Theo dõi truy vấn Workflow_Runs từ handler của nó vào pkg/github/client/client.go, sau đó so sánh việc lọc theo thời gian và xử lý phản hồi với pkg/models/workflows.go và pkg/github/workflows.go, là những phần bị PR #526 tác động. Tái hiện frame trống bằng truy vấn được cung cấp và so sánh request được tạo với curl thành công; hoàn thành khi các run đã biết điền đủ cả 14 trường cho phạm vi dashboard đã chọn.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Go
- Star
- 311
- Fork
- 72
- Merge trung bình
- 2 ngày 9 giờ
- Pull request đã merge (30 ngày)
- 2
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của grafana/github-datasource
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
grafana/github-datasource#796 · 2 bình luận ·
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 72/100
grafana/github-datasource#760 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
grafana/github-datasource#528 · 4 bình luận ·
-
Dependency DashboardĐang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 12/100
grafana/github-datasource#523 ·
-
prio/medium stale type/docs
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 30/100
grafana/github-datasource#509 · 1 bình luận ·
Tất cả issue của grafana/github-datasource
Issue tương tự
-
[Bug]: message-level cache_control on chat messages is dropped, so Anthropic prompt caching never triggersCó thể đã có người làm @Atharva-Kanherkar đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
Maintainer thường phản hồi trong vòng 1 ngày
-
documentation good first issue help wanted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
eugenioenko/ttt#1000 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Billionmail/BillionMail#389 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Gentleman-Programming/gentle-ai#5603 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
good first issue help wanted v3
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
oras-project/oras-go#1621 ·
Maintainer thường phản hồi trong vòng 1 ngày