Skip to content

Handle ResumeResponse.is_done from the K-parallel backend - #164

Closed
yuxiang-wu wants to merge 1 commit into
devfrom
feature/parallelization
Closed

Handle ResumeResponse.is_done from the K-parallel backend#164
yuxiang-wu wants to merge 1 commit into
devfrom
feature/parallelization

Conversation

@yuxiang-wu

Copy link
Copy Markdown
Contributor

This branch contains the full parallelization backend work: the foundational correctness commit (atomic step allocation / task attribution / completion CAS) and the K-parallel feature commit described below. Deploy order: supabase migration -> meta-agent -> CLI patch.

fix: handle ResumeResponse.is_done from PR-2 backend (patch release)

The PR-2 backend's /runs/{id}/resume can finalize a run itself (promote a
scored-but-interrupted node → step budget met → run flipped completed, no runnable
work), signalling it with a new additive is_done: bool on ResumeResponse. This
backend deploys BEFORE the CLI's parallel features, so today's CLI must handle it.

Bug (pre-fix): is_done was ignored. Manual weco resume entered the
task-polling loop, saw run.status == "completed", and returned
OptimizationResult(success=False, reason="user_requested_stop") — reporting a
completed run as stopped/failed (weco/optimizer.py:307-317, entered at :998).
The silent auto-resume path (_silent_resume returning a bare bool) re-entered the
loop and hit the same misreport.

Fix (weco/optimizer.py):

  • is_done is parsed defensively — absent → False, so the CLI stays correct
    against an older backend (unchanged legacy behavior).
  • Manual resume_optimization short-circuits on is_done: prints a "Run already
    complete" success message (matching the existing completion output), reuses
    offer_apply_best_solution to fetch/apply the winning code, and exits True
    without entering the task loop.
  • _silent_resume now returns _SilentResumeOutcome{RESUMED, ALREADY_COMPLETE, FAILED}; _run_loop_with_auto_resume treats ALREADY_COMPLETE as terminal
    success (fires on_complete, returns a completed result, stops retrying) —
    mirroring how a normal is_done exits the loop.

Tests: tests/test_resume_is_done.py (is_done true → no loop / success; is_done
absent → legacy loop path; is_done false → legacy loop path) and two new cases in
tests/test_auto_resume.py for the ALREADY_COMPLETE outcome. Fully mocked, no
network. Run: pytest tests/test_auto_resume.py tests/test_resume_is_done.py.

Ships last in the deploy order (supabase → meta-agent → CLI).

The backend's resume endpoint can now finalize a run itself (promoting
a scored-but-interrupted node meets the step budget), signalled by a
new additive is_done field. That backend deploys before the CLI's
parallel features, so today's CLI must handle it: previously a manual
resume of such a run entered the task loop, saw the run completed, and
reported it as stopped/failed.

- is_done parsed defensively (absent -> False; unchanged behavior
  against an older backend).
- Manual resume short-circuits on is_done: acquires the working-tree
  consumer lock, offers the best solution (skipping the apply with the
  standard message if the lock is unavailable), and exits successfully
  without entering the task loop.
- _silent_resume returns RESUMED / ALREADY_COMPLETE / FAILED; the
  auto-resume wrapper treats ALREADY_COMPLETE as terminal success.
- A 409 on result submit (run stopped mid-race) stays an error, never
  a completion — pinned by test.

Ships last in the deploy order: supabase migration -> meta-agent ->
this CLI patch.
@yuxiang-wu

Copy link
Copy Markdown
Contributor Author

Closing for now — this branch will be part of a single PR covering the complete parallelization feature once all phases are implemented.

@yuxiang-wu yuxiang-wu closed this Jul 13, 2026
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