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

log_abi_compile_erasure rebuilds libwirelog inside a parallel meson test run

Open
#1,651 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
56/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
c

Research direction

Start in tests/meson.build at the log_abi_compile_erasure registration, then inspect scripts/ci/check-log-erasure.sh and the related candidate_consumer_contract change in PR #1615. Add serial scheduling, review the timeout using check-shell-gate-walltime.py --fraction 0.5, and sweep registered scripts for other nested builds. Done means the acceptance checks pass and the added serial wall-clock is reported.

Written by the indexing model from the issue text.

Description

bug p2-medium

Triage — 2026-09-22

Target: Infra-0.A. Priority: p2-medium.

Address nested-build contention and scheduling in log erasure checks. #1799/#1808/#1663 separately own correctness; do not conflate scheduling improvement with their fixes.

This scheduling/ownership update supersedes older milestone assignments below; original acceptance criteria remain binding. A target milestone is a completion target, not a requirement to delay ready work.

Discovery context

Architect validation of PR #1615. That PR fixed candidate_consumer_contract, which ran a full from-scratch release build inside meson test and both exceeded its own budget and starved a neighbour into a timeout. The fix was is_parallel: false. A sweep for siblings found one.

The defect

tests/meson.build:

test('log_abi_compile_erasure',
     find_program(meson.project_source_root() / 'scripts/ci/check-log-erasure.sh'),
     suite: 'abi',
     timeout: 180)

scripts/ci/check-log-erasure.sh runs meson setup ... --buildtype=release -Dwirelog_log_max_level=error followed by meson compile -C "${BUILD_DIR}" wirelog. So it is a full library rebuild, and it has no is_parallel: false — it runs concurrently with the rest of the suite, where meson test parallelism is ncpu and the nested ninja takes ncpu+2.

The registration comment at tests/meson.build already acknowledges the cost ("log_abi_compile_erasure keeps 180 because it rebuilds libwirelog"), so the rebuild is known; what is not addressed is that it competes with every other test while doing it.

This is the same mechanism that produced PR #1615's two CI failures, measured there as a 5.6x spread on identical work across legs of one run, and a neighbour timing out at 30.08s while the offender passed at 112.17s.

Why it matters now

PR #1615 raised col_rel_deep_copy to timeout: 120 partly because this gate remains a parallel full-build neighbour on the TSan legs, where that test legitimately costs ~29s. In other words the col_rel_deep_copy raise is currently doing double duty: covering both the gate PR #1615 serialised and this one, which it did not. Serialising this gate would let that be re-examined on its own merits.

Scope

  • Add is_parallel: false to log_abi_compile_erasure, and re-check its timeout: 180 once it no longer runs contended — serialised it should be faster, but check-shell-gate-walltime.py requires measured duration to stay under 50% of the registered timeout, so the two move together.
  • Sweep for any other registered test that nests a build; check-log-erasure.sh and the candidate-consumer runner were the two found by grepping registered scripts for meson setup.

Acceptance criteria

  • No registered test runs a nested meson compile concurrently with the rest of the suite.
  • check-shell-gate-walltime.py --fraction 0.5 green with the adjusted timeout.
  • The added serial wall-clock is stated, since it is paid on every leg that runs an unfiltered meson test.

Related

  • PR #1615 — same mechanism, fixed for candidate_consumer_contract
Dominant language
C
Stars
18
Forks
2
Avg merge
6h 16m
Merged PRs (30d)
286

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.