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

Per-mutant timeout budget is parallelism-blind — full-core runs convert contention into spurious timeout verdicts

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

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

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
38/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Ít trao đổi
Công nghệ
django, postgresql, python
Lĩnh vực
databases, performance, testing-qa

Hướng nghiên cứu

Bắt đầu với việc tính timeout cho từng mutant được mutmut run sử dụng, bao gồm ngân sách (estimated_time_of_tests + 1) * 15 / * 30 và cách xử lý --max-children. Sau đó kiểm tra hành vi tiếp tục chạy đối với các kết quả đã được lưu trong cache ở mutants/; tái hiện sự khác biệt về điểm số bằng các lần chạy sạch với số lượng tiến trình con khác nhau, và xác định hoàn thành là ngăn các verdict timeout liên quan đến việc chạy song song hoặc xử lý rõ ràng các verdict đã lưu trong cache nhưng không tương thích.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

[boxed/mutmut] Per-mutant timeout budget is parallelism-blind — full-core runs convert contention into spurious ⏰ verdicts

Summary

The per-mutant wall/CPU budget ((estimated_time_of_tests + 1) * 15 / * 30) is computed from a solo-run estimate, but mutmut run defaults to forking one child per core, all hammering the same test database and CPUs. Under that contention each child's covering set runs several times slower than the estimate assumes, so the fixed deadline converts scheduler contention into timeout verdicts.

Measurements (6-core runner, DB-bound Django suite)

  • Default parallelism, cold cache: run "finishes" in ~20 min with 616 ⏰ at ~1 s per "timeout" — the verdicts are contention artifacts, not scores.
  • Same tree, mutmut run --max-children 2, cold cache: 708 🎉 / 24 🙁 / 366 ⏰ in ~83 min (~96.7 % of scored mutants killed) — the residual ⏰ being the fixed-budget issue reported separately (missing call.when filter starves the estimate).

So the same code and tests score wildly differently depending only on child count — and nothing warns about it.

Compounding trap: cached ⏰ verdicts replay as final

Resume-from-cache replays previously recorded ⏰ verdicts across config generations: after changing the covering set's cost (or --max-children), a "resumed" run still reports the old timeouts. A meaningful re-score requires a cold mutants/ — worth documenting, or invalidating cached ⏰ (only ⏰) on config change.

Suggested fixes (any of)

  1. Scale the deadline by the number of concurrent children (estimate × children is a cheap upper bound for a shared-resource suite).
  2. Re-measure the baseline estimate AT the configured parallelism before scoring.
  3. Expose the multiplier/constant as config (the ask in closed #492) so operators can compensate explicitly.
  4. At minimum: document that DB-bound suites need --max-children well below core count, and that ⏰ verdicts from a differently-parallel run must not be resumed.

Environment

  • mutmut 3.x, pytest 8.x, Django + Postgres suite, 6-core Linux runner
  • Related: #492 (closed — configurable multiplier), #518 (wrong est-lookup key), and our separate report on the call.when recording bug.
Ngôn ngữ chính
Python
Star
1.5k
Fork
185
Merge trung bình
1 ngày 14 giờ
Pull request đã merge (30 ngày)
5

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

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 boxed/mutmut

Tất cả issue của boxed/mutmut

Issue tương tự

Thêm issue về Python

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.