The previous version snapshotted last_run_id after the 201 response,
but jobs fire immediately server-side — by the time the client fetched
/api/jobs the runs were already complete, so the baseline matched the
new state and the poll loop never detected completion.
Baseline is now captured before the creation POST so it always
reflects pre-run state regardless of job speed.
The previous version snapshotted last_run_id after the 201 response,
but jobs fire immediately server-side — by the time the client fetched
/api/jobs the runs were already complete, so the baseline matched the
new state and the poll loop never detected completion.
Baseline is now captured before the creation POST so it always
reflects pre-run state regardless of job speed.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The previous version snapshotted last_run_id after the 201 response,
but jobs fire immediately server-side — by the time the client fetched
/api/jobs the runs were already complete, so the baseline matched the
new state and the poll loop never detected completion.
Baseline is now captured before the creation POST so it always
reflects pre-run state regardless of job speed.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
josh
scheduled this pull request to auto merge when all checks succeed 2026-03-28 20:43:13 -04:00
josh
merged commit e2935c58c8 into dev2026-03-28 20:43:26 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The previous version snapshotted last_run_id after the 201 response,
but jobs fire immediately server-side — by the time the client fetched
/api/jobs the runs were already complete, so the baseline matched the
new state and the poll loop never detected completion.
Baseline is now captured before the creation POST so it always
reflects pre-run state regardless of job speed.
Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com