Skip to content

[Docs] Report the conv_route_batch_after fix as merged, in all four places it appears - #24

Merged
rwkeyes merged 1 commit into
dirigo/0.2.12-verifiedfrom
docs/report-the-fix
Nov 15, 2026
Merged

rwkeyes merged 1 commit into
dirigo/0.2.12-verifiedfrom
docs/report-the-fix

Conversation

@rwkeyes

@rwkeyes rwkeyes commented Nov 15, 2026

Copy link
Copy Markdown
Owner

Problem

b906f0b5 merged the conv_route_batch_after fix, but the pages that report it still describe it as open — and the
0.2.13 fork-vs-stock report never mentions that neither of its binaries read that key.

Result

page change
docs/PERF-NEXT.md §7 "Fixed in PR #16 (unmerged…)" → fixed and merged in b906f0b5, with the resolution order (flag → config → 4), the test that pins all four cases, and the statement that it is behaviour-neutral for the deployment
DIRIGO.md the config-lever list now says conv_route_batch_after is only honoured from b906f0b5; before that a config edit looked applied and was not
dirigo-results/0.2.13-port/README.md records that neither measured binary read the key, so both arms served at the default 4 — symmetric, comparison unaffected, but a config-only change would not have shown up
dirigo-results/notes/improvements-2026-11-08.md item 1 proposed "2 vs 4 vs 6, a config key, one restart per arm"; kept as the dated record, closed with a pointer, including the fact that the experiment as proposed would have measured nothing

Validation

  • No broken relative link or anchor in any of the four edited pages (checked against GitHub's heading-slug rule plus
    explicit <a name>/<a id> anchors).
  • All five pages still render every table (README 8/60, DIRIGO 6/42, PERF-NEXT 11/80, 0.2.13-port 7/46, improvements
    8/37).
  • The claim "behaviour-neutral for the deployment" is the one verified when the fix merged: the launcher sets
    CONV_ROUTE_BATCH_AFTER=4, and resolve_batch_after(None, {"conv_route_batch_after": 4}) returns 4.

Limits

  • The 0.2.13 report's numbers are untouched: this is a disclosure note, not a re-measurement. Neither arm is re-run
    against the fixed server, and the report says so rather than implying it.

…appears

The fix landed (b906f0b), but three pages still described it as open,
and one measured report never mentioned that neither of its binaries
read the key at all.

- docs/PERF-NEXT.md §7 said "unmerged - it must not touch serve/ on
  this branch". It is merged, with the resolution order, the test, and
  the note that it is behaviour-neutral for the deployment.
- DIRIGO.md lists conv_route_batch_after as a config lever; that is only
  true from b906f0b onward, so the list now says so. A reader who had
  tried to set it from the config would otherwise trust a page that was
  wrong at the time.
- dirigo-results/0.2.13-port/README.md: neither arm of the fork-vs-stock
  run read that key, so both served at the default 4. Symmetric and it
  does not move the comparison, but a config-only change would not have
  shown up - that belongs in the report, not only in the inventory.
- dirigo-results/notes/improvements-2026-11-08.md: its item 1 proposed
  "2 vs 4 vs 6, a config key, one restart per arm". Kept as the dated
  record, closed with a pointer to what actually happened, including that
  the proposed experiment would have measured nothing.

Verified: no broken link or anchor in any of the four pages, all five
front-door pages still render every table, and .0.2.13-port's provenance
paragraph remains accurate as written.
@rwkeyes
rwkeyes merged commit 4291b70 into dirigo/0.2.12-verified Nov 15, 2026
3 checks passed
@rwkeyes
rwkeyes deleted the docs/report-the-fix branch November 15, 2026 12:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant