Commit e6e261c
committed
delegate.js: don't silently discard a checkpoint when resuming with max_steps below steps already completed
Previously, resuming with a max_steps ceiling lower than checkpoint.stepsDone
meant startStep > cappedSteps, so the loop body never ran -- it fell straight
through to deleteCheckpoint() + the generic "stopped after reaching the step
cap" message, discarding a checkpoint that had real completed work in it
without ever surfacing that work or explaining what happened. Added an
explicit guard right after the checkpoint state is established: if there's
nothing new to do because the requested ceiling is already met/exceeded,
leave the checkpoint alone (still resumable with a higher max_steps) and
return the existing transcript with a message that says so plainly.1 parent db61b82 commit e6e261c
1 file changed
Lines changed: 22 additions & 0 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
860 | 860 | | |
861 | 861 | | |
862 | 862 | | |
| 863 | + | |
| 864 | + | |
| 865 | + | |
| 866 | + | |
| 867 | + | |
| 868 | + | |
| 869 | + | |
| 870 | + | |
| 871 | + | |
| 872 | + | |
| 873 | + | |
| 874 | + | |
| 875 | + | |
| 876 | + | |
| 877 | + | |
| 878 | + | |
| 879 | + | |
| 880 | + | |
| 881 | + | |
| 882 | + | |
| 883 | + | |
| 884 | + | |
863 | 885 | | |
864 | 886 | | |
865 | 887 | | |
| |||
0 commit comments