compaction and diff_join remain at the 30s default, and the #1575 reproducer table will disagree with meson
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start with the registrations at tests/meson.build:3623 and tests/meson.build:3764, then read scripts/ci/diagnose-arm-sanitizer-timeouts.py and its test, scripts/ci/test-diagnose-arm-sanitizer-timeouts.py. Measure the tests on sanitizer and TSan legs before deciding whether explicit timeouts are needed; check whether the reproducer deadline should come from Meson introspection or be documented as independent. Done means all three tests have a recorded measurement and justified timeout choice, and the deadline source is clear.
Written by the indexing model from the issue text.
Description
Triage — 2026-09-22
Target: Infra-0.A. Priority: p2-medium.
Reconcile diagnostic deadlines and measure compaction/diff_join before changing their budgets. The old claim of literal 30s TSan deadlines is stale: runtime TSan now uses --timeout-multiplier 4. PR #1809 fixes only mem_report_contract and does not close this broader issue.
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
PR #1615 raised col_rel_deep_copy from Meson's 30s default to timeout: 120, because it timed out at 30.08s on TSan / ubuntu-latest / gcc. It was the only one of its class that was red, so it was the only one raised — deliberately, to keep a CI repair from widening into a timeout-hygiene sweep. This issue records what was left.
Closed issue #1575 observed the class directly: "compaction, diff_join and col_rel_deep_copy exceeded 30 seconds", and its scope said to "diagnose the adjacent timeout observations or link separately scoped follow-ups". #1575 is closed, so this is that follow-up.
1. Two siblings still at the default
tests/meson.build:3623 test('compaction', test_compaction_exe)
tests/meson.build:3764 test('diff_join', test_diff_join_exe)
scripts/ci/diagnose-arm-sanitizer-timeouts.py tracks both at a 30s deadline, alongside col_rel_deep_copy. This project registers no add_test_setup, so there is no timeout_multiplier: the 30s default is literal on the sanitizer and TSan legs, where these tests are instrumented and slow.
For scale, on a green main TSan run col_rel_deep_copy measured 24.54s against that same 30s — 82% of budget with no contention at all. Neither sibling has been measured that close, but neither has been measured deliberately either.
2. The reproducer table will diverge once PR #1615 merges
scripts/ci/diagnose-arm-sanitizer-timeouts.py:
TARGETS = {
"test_compaction": 30,
"test_diff_join": 30,
"test_col_rel_deep_copy": 30,
...
}
After PR #1615 lands, tests/meson.build says 120 for col_rel_deep_copy while this table still says 30. scripts/ci/test-diagnose-arm-sanitizer-timeouts.py pins the literal dict rather than cross-checking meson introspection, so nothing will ever flag the divergence. The diagnostic keeps working — it has its own deadline by design — but anyone reading its output needs to know the bound is the script's, not the registration's.
Scope
- Measure
compactionanddiff_joinon the sanitizer and TSan legs and give them explicit, justified timeouts if they are near budget. Do not bump them blind; the value should be explicit and justified, which is the rule the surrounding registrations already follow. - Decide whether
TARGETSshould be derived frommeson introspect --testsrather than hardcoded, or whether the intentional divergence should be asserted and commented.
Acceptance criteria
- Each of the three tracked 30s-default tests either carries an explicit timeout with a recorded measurement, or has a recorded measurement showing the default is comfortable.
- The #1575 reproducer's deadline source is either derived from the registration or documented as deliberately independent.
Related
- #1575 (closed) — original observation of the class
- PR #1615 — raised
col_rel_deep_copyonly - #1488, #1489 — the explicit-timeout rule for Python- and PowerShell-seeded gates
- Dominant language
- C
- Stars
- 18
- Forks
- 2
- Avg merge
- 6h 16m
- Merged PRs (30d)
- 286
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
-
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
-
bug
Difficulty 4/5 1-2 days Newbie friendliness 54/100
semantic-reasoning/wirelog#2202 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
semantic-reasoning/wirelog#2201 ·
Maintainers usually reply within 1 day
All issues in semantic-reasoning/wirelog
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 8 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
native-cpu: -Wreturn-type in skainet_row_threads.c:150 (worker fn has no return)Possibly taken @Doomguy-BFG9000 claimed this today. Opengood first issue size:xs skill:native
Difficulty 1/5 Under an hour Newbie friendliness 78/100
SKaiNET-developers/SKaiNET#1358 · 1 comment ·
Maintainers usually reply within 1 day
-
I/O internal correctness medium priority rt_lib
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
Maintainers usually reply within 1 day