[Bug][Dashboard] Engineering Throughput PR time panels count PRs without a project_pr_metrics row as 0 hours
Maintainer thường phản hồi trong vòng 2 ngày
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- Nửa ngày
- Mức phù hợp với người mới
- 22/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- grafana, mysql, postgresql, sql
- Lĩnh vực
- data-visualization, databases
Hướng nghiên cứu
The affected queries live in the Engineering Throughput and Cycle Time dashboard JSON files, in both MySQL and PostgreSQL variants, including the team-view file. Start with the LEFT JOIN project_pr_metrics plus coalesce(..., 0) in the PR Cycle Time query, and check whether PRs without a metrics row are excluded. Done means those PRs no longer count as 0 h and the panels show No data when no row exists. PR #9226 is already open against this issue, so check it before starting.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Search before asking
- I had searched in the issues and found no similar issues.
What happened
The PR time panels of the Engineering Throughput and Cycle Time dashboards treat a merged PR that has no
row in project_pr_metrics as a PR that took 0 hours. The PR should be left out of the average instead.
Affected panels (MySQL and PostgreSQL variants of each dashboard):
| Dashboard | Panels |
|---|---|
engineering-throughput-and-cycle-time.json |
PR Cycle Time, PR Coding Time, PR Pickup Time, PR Review Time, PR Deploy Time |
engineering-throughput-and-cycle-time-team-view.json |
Total Cycle Time(h), PR Coding Time(h), PR Pickup Time(h), PR Review Time(h), PR Deploy Time(h) |
All ten queries have the same shape (MySQL version of PR Cycle Time, trimmed):
with _prs as (
SELECT
pr.id,
pr.merged_date as pr_merged_date,
coalesce(prm.pr_cycle_time/60, 0) as cycle_time -- a missing row becomes 0
FROM pull_requests pr
left join project_pr_metrics prm on pr.id = prm.id
join project_mapping pm on pr.base_repo_id = pm.row_id and pm.table = 'repos'
WHERE $__timeFilter(pr.merged_date) and pm.project_name in (${project})
GROUP BY 1,2,3
)
SELECT ..., avg(cycle_time) FROM _prs GROUP BY ...
The set of PRs and the time axis come from pull_requests, while the metric values come from
project_pr_metrics. Because of LEFT JOIN + coalesce(..., 0), a merged PR without a project_pr_metrics
row enters avg() as 0 and pulls the average down:
pull_requests project_pr_metrics value used by the panel
───────────── ────────────────── ───────────────────────
PR A (merged) ──▶ pr_cycle_time = 14h ──▶ 14h
PR B (merged) ──▶ pr_cycle_time = 10h ──▶ 10h
PR C (merged) ──▶ (no row) ──▶ 0h ◀ should be excluded
avg = 8h (expected: 12h)
project_pr_metrics is written only by the DORA plugin (calculateChangeLeadTime in
backend/plugins/dora/tasks/change_lead_time_calculator.go). The most common way to hit this bug is a project
with DORA metrics disabled. In that case pull_requests has merged PRs, but project_pr_metrics has no rows
for them, so all five panels show a flat 0 h. It looks as if every PR was finished instantly, when in fact
no PR time data is available. The dashboard's "Data Sources Required" text does not mention DORA, so users
have no hint about the cause.
The bug depends only on whether a PR has a matching project_pr_metrics row. The reason the row is missing
does not matter.
What do you expect to happen
PRs without a project_pr_metrics row should be left out of these averages (removed from the denominator)
instead of being counted as 0.
If no PR in the selected range has a row (e.g. DORA is not enabled for the project), the panels should show
"No data" instead of 0 h.
How to reproduce
- Create a project with a GitHub or GitLab repository and keep DORA metrics disabled in the project settings.
- Collect data so that
pull_requestscontains merged PRs. - Open Engineering Throughput and Cycle Time (or its Team View) and select the project.
- PR Cycle / Coding / Pickup / Review / Deploy Time show 0 h in every period, even though there are merged PRs.
To count the merged PRs that these panels average in as 0:
SELECT count(*)
FROM pull_requests pr
JOIN project_mapping pm ON pr.base_repo_id = pm.row_id AND pm.`table` = 'repos'
LEFT JOIN project_pr_metrics prm ON pr.id = prm.id
WHERE pr.merged_date IS NOT NULL
AND pm.project_name = '<your project>'
AND prm.id IS NULL;
Anything else
Proposed fix (open to discussion)
- In the 20 affected queries (2 dashboards × 5 panels × MySQL/PostgreSQL), change
LEFT JOIN project_pr_metricsto an innerJOIN. - Keep the existing
coalesce(..., 0)on the per-row values. The comment above it says the goal is to
"make sure cycle_time equals the sum of the four metrics". A row can still have a NULL coding, pickup, review
or deploy time, and those values are still treated as 0. All five panels still average over the same set of
PRs (those that have a row), so this intent is preserved. The only change is that PRs with no row at all are
dropped. - When DORA is enabled, every merged PR in the project gets a row, so those projects see no change in values.
Only the "no row" case changes, from 0 h to excluded (or "No data").
Not affected (no change needed)
dora-details-lead-timefor-changes.jsonuses the sameLEFT JOIN+coalescepattern, but filters on
$__timeFilter(prm.pr_deployed_date), which already drops PRs without a row.DORA.json,dora-by-team.json,kiro-dora.json,kiro-credits-dora.json,
github-copilot-dora-correlation.jsonandmonorepo-subprojects.jsoneither inner-join or select directly
fromproject_pr_metrics, orAVG()the nullable column withoutcoalesce(NULLs are skipped).
Related
- #7398 reported PR Cycle Time showing 0 when data is incomplete. This issue is a different case: the PR has
noproject_pr_metricsrow at all.
Version
v1.0.3-beta15 (the same queries are still on main at 4ad2f66df)
Are you willing to submit PR?
- Yes I am willing to submit a PR!
Code of Conduct
- I agree to follow this project's Code of Conduct
- Ngôn ngữ chính
- Go
- Star
- 3.2k
- Fork
- 824
- Merge trung bình
- 2 ngày 22 giờ
- Pull request đã merge (30 ngày)
- 43
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Không 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 apache/devlake
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
Maintainer thường phản hồi trong vòng 2 ngày
-
[Bug][Project] Invalid metric plugin options are accepted on project save and only fail at the next pipeline runCó thể đã có người làm @chenwei791129 đã nhận 3 ngày trước. Đang mở
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 22/100
Maintainer thường phản hồi trong vòng 2 ngày
-
[Bug][e2e] Several plugin e2e tests fail on a fresh database because they depend on tables created by other testsCó thể đã có người làm @chenwei791129 đã nhận 4 ngày trước. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
Maintainer thường phản hồi trong vòng 2 ngày
-
[Feature][dora] Allow filtering which pull requests count toward Lead Time for Changes by branch nameCó thể đã có người làm @chenwei791129 đã nhận 3 ngày trước. Đang mở
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 15/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 3/5 Nửa ngày Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của apache/devlake
Issue tương tự
-
Chained slog With calls discard previously bound attributesCó thể đã có người làm @yuefdev đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[scanner] TestAgentNowLineStates hard-fails instead of degrading when node is off PATHCó thể đã có người làm @arteeh đã nhận hôm nay. Đang mởagent/scanner ci help wanted kind/test
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
hivecommons/hive#12924 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Gentleman-Programming/engram#1940 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
cloudflare/terraform-provider-cloudflare#7423 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
devices
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
evcc-io/evcc#35007 · 7 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày