Skip to content

Re-grade workflow: 4 evaluator workers by default, log memory - #252

Merged
yl231 merged 1 commit into
mainfrom
ci/regrade-workers
Oct 29, 2026
Merged

yl231 merged 1 commit into
mainfrom
ci/regrade-workers

Conversation

@yl231

@yl231 yl231 commented Oct 29, 2026

Copy link
Copy Markdown
Contributor

Fixes the re-grade workflow from #244. Its first full run (run 40967618215) lost all 10 of its first jobs.

What happened: each runner received a shutdown signal (exit 143) about 2 minutes into grading, with 16 worker threads. No Python error was logged, and every job died at the same stage regardless of router. The PR evaluation workflow grades the same files on the same runner type and succeeds. Running out of memory is the likely cause, but the logs couldn't confirm it, because --save-interval 0 also silenced the progress lines.

Change:

  • The number of evaluator workers is now an input, num_workers, defaulting to 4.
  • Progress is logged every 10 rows, as in the PR evaluation.
  • Memory and swap use are printed every 30 seconds while grading, so a failure shows its cause.

I'll test it on one router before re-running all 25.

🤖 Generated with Claude Code

The first full re-grade run lost all ten of its first jobs: each runner got a
shutdown signal about two minutes into grading with 16 worker threads, while
the PR evaluation of the same files succeeds. The worker count is now an input
(default 4), progress is logged as in the PR evaluation, and memory and swap
use are printed every 30 seconds so a failure shows its cause.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@yl231
yl231 merged commit 5a342c5 into main Oct 29, 2026
12 checks passed
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