Skip to content

recipes: fork global-input key self-tests - #794

Merged
juliankang4 merged 1 commit into
midagedev:mainfrom
juliankang4:fix-check-recipes-fork-the-key
Oct 24, 2026
Merged

juliankang4 merged 1 commit into
midagedev:mainfrom
juliankang4:fix-check-recipes-fork-the-key

Conversation

@juliankang4

Copy link
Copy Markdown
Collaborator

check-recipes의 key self-test에서 가장 오래 걸리는 구간을 둘로 나눠 병렬로 돌려, 전체 검사 시간을 줄이는 변경입니다.

What and why

key_self_test in tools/recipes.py runs as five forked sections, one per section value. The inputs section was the longest block of check-recipes, because it also held the loop over KEY_GLOBALS. That loop edits each of the five global inputs in turn and re-analyses every key, one after another, inside the inputs job.

This PR gives the loop its own section, globals, and adds it to the existing list of forked self-test jobs. The remaining inputs checks stay in their job. Each new fork builds its own scratch tree, manifest and temporary HOME through the same code path as the other sections. The inputs guard now wraps the code before the loop and the code after it, so a run without a section (section=None) keeps its old order. The key analysis and cache code are untouched, and no assertion is added, removed or relaxed.

Release notes: Under the hood: check-recipes runs the global-input key self-tests in their own parallel section and finishes sooner.

Code shape

  • No second copy. No new function, constant or helper. The new section reuses _forked and key_self_test, and the fixture setup is still written once.
  • Model code holds only architecture facts. No model or engine code changes.
  • Dead code is gone. Nothing became unused.
  • No silent failure. The section assertion still refuses an unknown value; it only gains globals as an allowed one. A failure in the new fork is reported through the existing _forked path.
  • Comments state what is true now. No comments added.
  • No relaxed gate. No assertion, case, band, tolerance or PIN changed.
  • cargo fmt and cargo clippy: no Rust changes (one Python file).

Duplication found or removed (path:line), or "none": none.

What I ran

Hardware: one Linux x86_64 machine with an AMD Ryzen 5 PRO 6650H and 11 GiB of RAM, no GPU. Both arms ran bash tools/check-recipes.sh pinned to four logical CPUs with four scheduler slots, under CPython 3.12.15 and RUSTFLAGS='-C target-cpu=x86-64-v3'.

Main was upstream c076199f660e1dc10a27885d8488ae42fb0ab7f0 and the head was this patch on it. After the measurement, upstream moved and the branch was rebased onto 27776a21ffe7364b878c4125a00f3157d71bdc2a. The rebase left the patch unchanged (git range-diff shows =), and tools/recipes.py is identical in the two bases. Other upstream files, including tools/check-recipes.sh, did change, so the table below is for the earlier base and I did not measure the full check on the final head.

I ran main first and then the head, once each, so this is one pair of observations with no estimate of run-to-run noise. The head ran in a separate session from main, and the two arms were not alternated. Wall time is the time of static-sched.py run --max 4 plus check-recipes.sh --report on the same job list, with the list generation left out.

Arm check-recipes wall self-test block Blocks run Failed or skipped
main 769.155 s 761.2 s 147 0
head 751.549 s 694.1 s 147 0

The wall time dropped by 17.606 s, 2.29% [derived]. The self-test block dropped by 67.1 s [derived], but the whole check dropped by much less. The sections run in parallel, so their times do not add up. On the head the other key sections took longer (reach 541 s to 632 s, scope 451 s to 542 s, fixtures 409 s to 491 s, variants 232 s to 271 s), and the last blocks to finish were pytools.26 at 749.7 s and treecommit at 750.7 s, after the self-test block ended at 701.2 s. I do not claim that the change reduces CPU work: the extra fork repeats one fixture setup.

Both arms ran the same 147 block names, all with return code 0 and none skipped. In both, recipes.py --self-test reports 227 gate recipes, 0 failures and the key CLI self-test reports 27 passed, 0 failed.

FAIL-first and structure check: a one-off script, not part of this PR, runs the real jobs expression of self_test and evaluates the real section guards. On main it fails with global loop routed to inputs: True. On the head it passes, with 94 key assertions whose syntax trees match the original, the KEY_GLOBALS loop identical, the serial order preserved and all five sections dispatched with their own binding. Four planted mutants are each caught: a missing globals job, a lambda that drops section=section, the loop moved back into inputs, and the loop's assertion deleted.

Not run: just contrib-check (the CI T0 tier) on the final head, cargo clippy and cargo fmt (no Rust changes), and any GPU gate (no device code changes). The editor diagnostics for tools/recipes.py list existing Ruff and Pyright findings in the file; none is on a line this PR changes.

Reproduction

python3 tools/recipes.py --self-test
bash tools/check-recipes.sh --jobs > jobs.tsv
python3 tools/static-sched.py run --max 4 --out blocks jobs.tsv
bash tools/check-recipes.sh --report blocks

Run the last three on main and on the head, and compare the elapsed time of the scheduler run and the report together.

What I ran into

This does not block the PR.

  • The gain is far smaller than the self-test block's drop suggests, because the other key sections and the late pytools.26 and treecommit blocks decide when the check ends. About 50 s of that tail remains after the self-test block finishes [derived]. Moving those two blocks earlier is a separate scheduling change that I did not try.
  • tools/bloomery/reach_cache.py prepare re-analyses once per root namespace. Reusing a bounded snapshot there could remove some of that repeated work without more forks, but I did not measure it.

AI help

AI 코딩 에이전트가 코드를 작성한 후 설명을 썼고, 테스트를 마쳤습니다. diff 리뷰와 PR 초안 리뷰는 제가 직접 했습니다.

@github-actions github-actions Bot added the tools Tools, recipes, CI and the toolchain: tools/, justfile, .github/, Cargo label Oct 24, 2026

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verdict: CLEAN: The split preserves key coverage, serial order, and failure reporting.

Checked

  • Duplicates: 0 new functions, types, or constants; the existing fixture setup and _forked remain the owners.
  • Complexity: no Rust functions changed; the Python change partitions an existing loop.
  • Silent failure: 2 error paths followed. Unknown sections assert; failed child jobs reach the self-test's nonzero exit.
  • Tests: independent AST checks confirm all 94 expectation sites are unchanged, unsectioned statement order is preserved, and all five jobs bind their section. The global loop runs only in globals; the other existing sections are unchanged. The moved assertion protects tools/recipes.py:8966: dropping global key parts leaves unchanged keys and fails the all-items comparison.
  • Gates: no assertion, threshold, or case removed or relaxed; no PIN moved.
  • Escape catalog: no C1–C4 pattern matched. Separate scratch trees and restored edits prevent cross-job interference.

Notes

Dryer and crapper do not apply to this Python-only diff. The full check-recipes suite was not run during validation; checks were structural. The PR reports successful runs before its final rebase, with no full check on the final head.

🔨 Shingler, bloomery's review bot: approves a clean pull request and requests changes on a must-fix (how it works)

@juliankang4

Copy link
Copy Markdown
Collaborator Author

The review is done and the contribution check passed, so I'm merging this.

@juliankang4
juliankang4 merged commit 4ef888c into midagedev:main Oct 24, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tools Tools, recipes, CI and the toolchain: tools/, justfile, .github/, Cargo

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant