Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Bug][dora] calculateChangeLeadTime loads the whole commits_diffs deployment join into memory

Đang mở
  • Có gì không ổn?
#9,280 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 2 ngày

@mdelacruz-avantio đang làm issue này rồi.

Từ ngày 29/10/2026.

  • #9281 của @mdelacruz-avantio — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
go
Lĩnh vực
backend, data-engineering

Hướng nghiên cứu

Start with batchFetchDeployments in backend/plugins/dora/tasks/change_lead_time_calculator.go and inspect how the second phase joins cicd_deployment_commits with commits_diffs. The issue proposes streaming rows into a three-column struct while preserving the joins, filters, ordering, and first-wins tie-break; an open pull request already tracks this work. Done means memory scales with distinct merge commits and the tie-break has an end-to-end test.

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

batchFetchDeployments in backend/plugins/dora/tasks/change_lead_time_calculator.go resolves merge commits to deployments in two phases. The second phase joins cicd_deployment_commits with commits_diffs, loads every joined row into a slice of full CicdDeploymentCommit structs with db.All, and only then keeps the first row per merge commit in Go.

Memory therefore grows with the size of the join, not with the number of merge commits. The join has one row per commit between a production deployment and its previous successful one, for every merge commit in that range. On a project where deployments are far apart in commit history, or where a deployment job records a commit from a second repository with a long history, the join becomes very large.

On our instance the query returns about 936,000 rows for 14,088 distinct merge commits (1,693 production deployment commits). The lake container peaks at about 1.7 GiB in this subtask, is OOMKilled at a 2 GiB limit on every nightly run, and then crash loops because each restart resumes the same pipeline at the same subtask. The row count grows every week.

What do you expect to happen

The memory used by this subtask stays proportional to the number of distinct merge commits, as the first phase already does, whatever the size of the commits_diffs join.

How to reproduce
  1. A project with a few hundred production deployment commits where consecutive deployments are thousands of commits apart, so commits_diffs holds many rows per deployment pair.
  2. Run the DORA pipeline and watch the lake container memory during calculateChangeLeadTime, or count the rows the second phase loads:
SELECT COUNT(*), COUNT(DISTINCT cd.commit_sha)
FROM cicd_deployment_commits dc
LEFT JOIN cicd_deployment_commits p ON dc.prev_success_deployment_commit_id = p.id
INNER JOIN commits_diffs cd ON cd.new_commit_sha = dc.commit_sha AND cd.old_commit_sha = COALESCE(p.commit_sha, '')
LEFT JOIN project_mapping pm ON pm.table = 'cicd_scopes' AND pm.row_id = dc.cicd_scope_id
WHERE dc.prev_success_deployment_commit_id <> '' AND dc.environment = 'PRODUCTION' AND dc.result = 'SUCCESS' AND pm.project_name = '<project>';

The first number is what the subtask materialises, the second is what it keeps.

Anything else

Streaming the second phase with db.Cursor and db.Fetch into a three-column struct and keeping the first row per merge commit, with the same joins, filters and ordering, makes the memory independent of the join size. I will open a pull request with that change and an e2e case for the first-wins tie-break.

Raising the container memory limit and setting GOMEMLIMIT is a stopgap only, the peak keeps growing with the join.

Version

v1.0.3-beta18. The function is unchanged on main at 625e512a4.

Ngôn ngữ chính
Go
Star
3.2k
Fork
830
Merge trung bình
2 ngày 12 giờ
Pull request đã merge (30 ngày)
61

Chuẩn bị môi trường

Mở trong Codespaces

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

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/devlake

Tất cả issue của apache/devlake

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.