test_evaluation_serial controlled STEP fails under WIRELOG_JOIN_BATCH_BYTES=224
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 58/100
Research direction
Start with tests/test_evaluation_serial.c around line 1706 and reproduce using WIRELOG_JOIN_BATCH_BYTES=224 meson test -C <build> evaluation_serial. Record the value returned by wl_session_step(session) under the knob, then trace controlled STEP work accounting against the batch-size-dependent fixture. Done when the test passes with the knob and the fix addresses either the accounting behavior or the fixture’s limit dependency.
Written by the indexing model from the issue text.
Description
Summary
With WIRELOG_JOIN_BATCH_BYTES=224, test_evaluation_serial aborts deterministically at
tests/test_evaluation_serial.c:1706: wl_session_step(session) == WL_EVALUATION_CONTROL_WORK_LIMIT
in test_controlled_session_step_resume. Without the knob, the test passes.
Reproduction
WIRELOG_JOIN_BATCH_BYTES=224 meson test -C <build> evaluation_serial
Bisect facts
- It reproduces on e4bcbea1 and on b63f3910.
- It first appears with b82ce75e, "feat(session): add controlled initial STEP (Refs #1821)", which added this test.
- It is unrelated to #2129 / #2246; it was found while running that PR's knob gate. In that gate it was the only failure: 344 ok, 1 fail.
Not established
I have not recorded which value wl_session_step returns under the knob. So it is open whether the knob changes how work is accounted, so the limit is never reached, or whether the controlled STEP path ignores the limit under batched joins. Deciding that is the first step: either fix the controlled STEP accounting, or make the fixture's work limit independent of join batch size.
- Dominant language
- C
- Stars
- 18
- Forks
- 2
- Avg merge
- 9h 28m
- Merged PRs (30d)
- 169
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
-
Difficulty 3/5 1-2 days Newbie friendliness 54/100
semantic-reasoning/wirelog#2244 ·
Maintainers usually reply within 1 day
All issues in semantic-reasoning/wirelog
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
update-request
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
msys2/MINGW-packages#33004 ·
Maintainers usually reply within 1 day
-
area:buffer good first issue type:documentation
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sudo-project/sudo#586 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100
OpenPrinting/cups#1795 ·
Maintainers usually reply within 1 day