Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Bound PR sanitizer job duration and preserve failure diagnostics

Open
  • Is something wrong?
#1,952 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
c, github-actions
Domain
build-system, ci-cd

Research direction

Start with .github/workflows/ci-pr.yml and the referenced sanitizer runs 36084238142, 36040046065, and 36072839458. Measure cache-cold setup, build/link, and test durations for all four sanitizer lanes before selecting a timeout. Preserve Meson/Ninja and test logs on failure or timeout, then run a controlled timeout check and verify coverage, required checks, failure propagation, and the downstream TSan dependency remain unchanged.

Written by the indexing model from the issue text.

Description

p2-medium

Discovery context

PR run 36084238142 exposed uncertainty around sanitizer-job runtime. Its first Ubuntu sanitizer attempt was cancelled after roughly 60 minutes. The completed logs show GCC had linked 4410/4417 targets and Clang 4416/4417; GCC cleanup showed active GCC/linker/LTO processes. A subsequent GCC attempt completed successfully in 1h15m20s. These observations show expensive late build work, not a hang or deadlock. The sanitizer-matrix job in .github/workflows/ci-pr.yml has no explicit project-selected job timeout.

Successful PR runs 36040046065 and 36072839458 recorded sanitizer lane job durations from about 25 minutes to 1h15m20s. Their cache-cold status is not established by the job API, so they are reference data rather than cold-run limits. A 60-minute cap would have interrupted the observed near-complete builds.

Scope

Measure and document sanitizer-matrix duration budgets and improve late-build diagnostics in .github/workflows/ci-pr.yml. Base any explicit job timeout on completed cold-run durations for all four sanitizer lanes, with headroom for dependency installation, full build including LTO, and tests. Add a separate build-stage timeout only if measurements justify it and leave enough time for best-effort diagnostics. Preserve the existing sanitizer coverage and required-check behavior.

Acceptance criteria

  • Measure cache-cold setup, build/link, and full-test durations for GCC/Linux, Clang/Linux, GCC/ARM64, and Clang/macOS.
  • Select and document an overall timeout from those measurements with cold-run headroom; do not set a 60-minute limit or infer remaining duration from a cancelled build's target count.
  • Add useful elapsed-stage/progress diagnostics for long builds and preserve available Meson/Ninja and test logs on failure or timeout; document that hard cancellation can prevent artifact upload.
  • If a shorter build-stage timeout is introduced, justify it from the measured lane data and leave diagnostic time before the job limit.
  • A controlled timeout check demonstrates a failing timeout result and best-effort diagnostic handling.
  • Keep all four sanitizer configurations, tests, required-check names, failure propagation, and downstream TSan dependency unchanged. Do not add retries, continue-on-error, or skipped sanitizer work.
Dominant language
C
Stars
18
Forks
2
Avg merge
10h 9m
Merged PRs (30d)
173

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from semantic-reasoning/wirelog

All issues in semantic-reasoning/wirelog

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.