Keep batch-append plan and collection tests within CI timeouts
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- c, github-actions
- Domain
- ci-cd, testing-qa
Research direction
Start with the perf_batch_append_plan_contract and perf_batch_append_collection_admission_contract Meson targets and their test fixtures; compare setup and test-body timings and fixture call counts standalone and under the parallel ABI suite. Gather runner-load evidence where available, then make changes only if measurements show repeated setup is material. Done means both targets pass under the stated hosted GCC and Clang conditions, within existing timeouts, while preserving all tests and private mutable artifacts.
Written by the indexing model from the issue text.
Description
Scope
Measure and keep the batch-append plan and collection ABI contract tests within their existing timeouts under normal parallel CI load. Profile setup and test-body time separately, including anchor-bundle fetch/source creation, plan/profile/calibration preparation, freeze construction, and collection admission. Reduce duplicated fixture work only where measurements show it is material; preserve each test's private mutable artifacts, provenance checks, cleanup, and negative cases. Do not increase timeouts, remove tests, or weaken assertions.
Discovery context
PR #2077's Ubuntu GCC run 37249449676 timed out these ABI tests in the same parallel suite: perf_batch_append_plan_contract at 120.04 s, perf_batch_append_command_freeze_contract at 180.47 s, and perf_batch_append_collection_admission_contract at 180.46 s. The command-freeze fixture is being optimized separately in PR #2074. The plan contract and collection contract remain outside that change; collection manually drives CommandFreezeTests.setUp() and needs an explicit shared-fixture lifecycle. The LFTJ tests in #2077 completed quickly, so the timeout evidence does not implicate its production changes.
A local run after the #2074 fixture changes passed the plan contract's 13 tests in 49.2 s and the collection contract's 8 tests in 74.4 s. Other CI lanes passed the same contracts substantially faster than the failed GCC primary lane, so the cause may include parallel runner contention. Repeated setup is visible, but its contribution has not yet been isolated.
Acceptance criteria
- Record per-test setup/body timings and the relevant fixture call counts for both contracts, standalone and under the normal parallel ABI suite; capture runner load or resource-pressure evidence where available.
- Keep all current tests, mutation/provenance assertions, and the existing 120 s plan and 180 s collection limits.
- Keep mutable plans, profiles, calibration evidence, and collection outputs private to each test; shared fixture inputs are integrity-checked and never shared through a reused
TestCaseinstance. - If measurements identify removable repeated setup as a material contributor, implement an isolated fixture optimization and show two consecutive full test-file runs with useful margin under the existing limits.
- Pass both exact Meson ABI targets standalone and in the normal parallel ABI suite on hosted GCC and Clang, with two consecutive hosted GCC primary runs below 80 s for plan and 120 s for collection.
- If runner contention dominates, document the evidence and test a narrowly scoped scheduling adjustment without blanket-serializing the ABI suite.
Priority and dependencies
P2, milestone 0.85.0. These required ABI contracts can be killed before completing their assertions, weakening confidence in regression coverage. This is CI reliability work rather than evidence of a confirmed production-code defect.
Depends on the final shared-fixture API and lifecycle from PR #2074. The timeout observations are independent of PR #2075's production optimization.
- Dominant language
- C
- Stars
- 18
- Forks
- 2
- Avg merge
- 9h 48m
- Merged PRs (30d)
- 165
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from semantic-reasoning/wirelog
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
semantic-reasoning/wirelog#2229 ·
Maintainers usually reply within 1 day
-
Doc: insert executor and incremental consolidation leave sorted runs, not globally sorted headsOpen
Difficulty 1/5 Under an hour Newbie friendliness 83/100
semantic-reasoning/wirelog#2133 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
semantic-reasoning/wirelog#2042 ·
Maintainers usually reply within 1 day
-
p2-medium
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
semantic-reasoning/wirelog#1914 ·
Maintainers usually reply within 1 day
-
enhancement track/semantics
Difficulty 5/5 Over a week Newbie friendliness 12/100
semantic-reasoning/wirelog#2305 ·
Maintainers usually reply within 1 day
All issues in semantic-reasoning/wirelog
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
CanadaHonk/porffor#426 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 77/100
raysan5/raylib.com#132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
libsdl-org/SDL#16607 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
PowerShell/Win32-OpenSSH#2482 · 1 reaction ·
-
needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SoftEtherVPN/SoftEtherVPN#2322 ·
Maintainers usually reply within 1 day