Overview
The SLOW-skip convention documents a "60s per-script timeout cap". No such cap is enforced anywhere. The real values are 300s (smoke/default) and 1800s (mode=release).
This is not cosmetic. A 5× understatement of the cap biases every "is this script too slow to un-skip?" judgement in the same direction — toward parking scripts that would in fact pass. It did exactly that during the triage of autolens_workspace_test#193 on 2026-07-22: a clean run of database/scrape/general measured 214s, which reads as a clear SLOW-skip against 60s but has ~86s of headroom against the real 300s cap. The correct call was to leave it un-skipped.
Where the real cap lives
- 300s —
autobuild/build_util.py:12, TIMEOUT_SECS = int(os.environ.get("BUILD_SCRIPT_TIMEOUT", "300")), matching autobuild/run_all.py:49 DEFAULT_TIMEOUT_SECS = 300.
- 1800s —
PyAutoHeart/.github/workflows/workspace-validation.yml:308 sets BUILD_SCRIPT_TIMEOUT: "1800" for the release run.
Plan
- Correct the three sites in
autobuild/slow_skip_check.py, sourcing the number from build_util.TIMEOUT_SECS instead of hardcoding a second copy that can drift again — and let run_all.py pass the timeout actually in effect for the run.
- Correct the identical stale line-9 header comment in all seven workspaces'
config/build/no_run.yaml.
Detailed implementation plan
Affected Repositories
- PyAutoHands (primary — the code and the report text)
- autolens_workspace, autolens_workspace_test, autogalaxy_workspace, autofit_workspace, autofit_workspace_test, HowToLens, HowToGalaxy (comment-only, one line each)
Suggested branch: feature/slow-skip-timeout-cap-doc
The three stale sites in autobuild/slow_skip_check.py
- Line ~18, module docstring — "SLOW entries indicate scripts that exceed the 60s per-script timeout cap".
- Line ~140,
_BANNER_CONFIG["slow"]["footer"] — "These scripts are skipped because they exceed the 60s per-script cap". Printed to stdout by run_all.py at lines 174 and 237.
- Line ~159,
_REPORT_CONFIG["slow"]["intro"] — "{n} script(s) are being skipped because they exceed the 60s per-script timeout cap". This one lands in the slow-skip section of every mega-run report.
Implementation Steps
autobuild/slow_skip_check.py: add import build_util (the established flat-import idiom in this package — generate.py, run.py, run_python.py, generate_autofit.py, generate_markdown.py all do it). Replace the hardcoded 60s in all three sites with the value from build_util.TIMEOUT_SECS, noting the release override.
- Thread an optional
timeout_secs argument through format_warning_banner and format_report_section, defaulting to build_util.TIMEOUT_SECS, so the text reflects the cap actually in force.
autobuild/run_all.py: pass timeout_secs (already in scope from args.timeout_secs) at the four banner/report call sites, so a --timeout-secs override is reported accurately rather than as the default.
- Seven workspaces: fix line 9 of
config/build/no_run.yaml.
Key Files
autobuild/slow_skip_check.py — the three stale sites.
autobuild/run_all.py — banner call sites (174, 237) and report section.
autobuild/build_util.py — TIMEOUT_SECS, the single source of truth.
<workspace>/config/build/no_run.yaml — line 9 header, × 7.
Follow-up worth considering (separate task)
The four database/scrape/* siblings (multi_analysis, slam_general, slam_multi_one_by_one, slam_pix) are still tagged # SLOW 2026-04-10 - exceeds 60s timeout. Those markers were written against the wrong cap; some may clear the real 300s cap and be un-parkable. Worth re-timing once this lands.
Original Prompt
Click to expand starting prompt
PyAutoMind/draft/bug/pyautobuild/slow_skip_60s_timeout_cap_is_wrong.md
Overview
The SLOW-skip convention documents a "60s per-script timeout cap". No such cap is enforced anywhere. The real values are 300s (smoke/default) and 1800s (
mode=release).This is not cosmetic. A 5× understatement of the cap biases every "is this script too slow to un-skip?" judgement in the same direction — toward parking scripts that would in fact pass. It did exactly that during the triage of autolens_workspace_test#193 on 2026-07-22: a clean run of
database/scrape/generalmeasured 214s, which reads as a clear SLOW-skip against 60s but has ~86s of headroom against the real 300s cap. The correct call was to leave it un-skipped.Where the real cap lives
autobuild/build_util.py:12,TIMEOUT_SECS = int(os.environ.get("BUILD_SCRIPT_TIMEOUT", "300")), matchingautobuild/run_all.py:49DEFAULT_TIMEOUT_SECS = 300.PyAutoHeart/.github/workflows/workspace-validation.yml:308setsBUILD_SCRIPT_TIMEOUT: "1800"for the release run.Plan
autobuild/slow_skip_check.py, sourcing the number frombuild_util.TIMEOUT_SECSinstead of hardcoding a second copy that can drift again — and letrun_all.pypass the timeout actually in effect for the run.config/build/no_run.yaml.Detailed implementation plan
Affected Repositories
Suggested branch:
feature/slow-skip-timeout-cap-docThe three stale sites in
autobuild/slow_skip_check.py_BANNER_CONFIG["slow"]["footer"]— "These scripts are skipped because they exceed the 60s per-script cap". Printed to stdout byrun_all.pyat lines 174 and 237._REPORT_CONFIG["slow"]["intro"]— "{n} script(s) are being skipped because they exceed the 60s per-script timeout cap". This one lands in the slow-skip section of every mega-run report.Implementation Steps
autobuild/slow_skip_check.py: addimport build_util(the established flat-import idiom in this package —generate.py,run.py,run_python.py,generate_autofit.py,generate_markdown.pyall do it). Replace the hardcoded60sin all three sites with the value frombuild_util.TIMEOUT_SECS, noting the release override.timeout_secsargument throughformat_warning_bannerandformat_report_section, defaulting tobuild_util.TIMEOUT_SECS, so the text reflects the cap actually in force.autobuild/run_all.py: passtimeout_secs(already in scope fromargs.timeout_secs) at the four banner/report call sites, so a--timeout-secsoverride is reported accurately rather than as the default.config/build/no_run.yaml.Key Files
autobuild/slow_skip_check.py— the three stale sites.autobuild/run_all.py— banner call sites (174, 237) and report section.autobuild/build_util.py—TIMEOUT_SECS, the single source of truth.<workspace>/config/build/no_run.yaml— line 9 header, × 7.Follow-up worth considering (separate task)
The four
database/scrape/*siblings (multi_analysis,slam_general,slam_multi_one_by_one,slam_pix) are still tagged# SLOW 2026-04-10 - exceeds 60s timeout. Those markers were written against the wrong cap; some may clear the real 300s cap and be un-parkable. Worth re-timing once this lands.Original Prompt
Click to expand starting prompt
PyAutoMind/draft/bug/pyautobuild/slow_skip_60s_timeout_cap_is_wrong.md