fix(intake): Regenerate re-queues the draft but never wakes the worker #272

New Issue

2026-09-02T16:54:39-05:00

bermudalamb commented

2026-09-02 16:54:39 -05:00

Pressing Regenerate in the review queue appears to do nothing.

It is not doing nothing — it sets state='queued', clears attempts and ai_error, and answers 200. But nothing then runs the worker, so the draft sits queued until the five-minute sweeper happens along. From the admin's side that is indistinguishable from a dead button, and the obvious response is to press it again.

The omission

The submission path kicks the worker immediately after committing:

void draftQueued(1).catch((err) => console.error('[drafting] after submission:', err));

The regenerate route in adminItemDrafts.ts does not. Both put a row into queued; only one asks for it to be drafted. That is an oversight in #225 rather than a decision — the plan added the kick to the submission path in a later task and never came back to the action routes.

The same applies to the signed regenerate link from the notification email (#224), which sets the identical state through intakeActions.ts.

Fix

Call draftQueued(1) after both regenerate routes, fire-and-forget with a logged catch, exactly as the submission path does. A slow or failing model call must not turn into a failed request for the admin, and the sweeper remains the backstop if the kick fails.

Worth considering separately

Even with an immediate kick, the card does not update itself — the drafting takes a few seconds and the screen has no way to know it finished. Refresh shows it. Whether that needs polling or a spinner is a UI question rather than this bug, and is not worth doing until drafting actually succeeds (#271).

Found while testing #223 task 8 in QA.

Pressing **Regenerate** in the review queue appears to do nothing. It is not doing nothing — it sets `state='queued'`, clears `attempts` and `ai_error`, and answers 200. But nothing then runs the worker, so the draft sits queued until the five-minute sweeper happens along. From the admin's side that is indistinguishable from a dead button, and the obvious response is to press it again. ## The omission The submission path kicks the worker immediately after committing: ```ts void draftQueued(1).catch((err) => console.error('[drafting] after submission:', err)); ``` The regenerate route in `adminItemDrafts.ts` does not. Both put a row into `queued`; only one asks for it to be drafted. That is an oversight in #225 rather than a decision — the plan added the kick to the submission path in a later task and never came back to the action routes. The same applies to the signed **regenerate** link from the notification email (#224), which sets the identical state through `intakeActions.ts`. ## Fix Call `draftQueued(1)` after both regenerate routes, fire-and-forget with a logged catch, exactly as the submission path does. A slow or failing model call must not turn into a failed request for the admin, and the sweeper remains the backstop if the kick fails. ## Worth considering separately Even with an immediate kick, the card does not update itself — the drafting takes a few seconds and the screen has no way to know it finished. Refresh shows it. Whether that needs polling or a spinner is a UI question rather than this bug, and is not worth doing until drafting actually succeeds (#271). Found while testing #223 task 8 in QA.

bermudalamb referenced this issue from a commit

2026-09-02 17:11:13 -05:00

fix(intake): wake the worker when a draft is regenerated (#272)

bermudalamb referenced this issue from a commit

2026-09-02 17:25:07 -05:00

fix(intake): wake the worker when a draft is regenerated (#272)

bermudalamb closed this issue

2026-09-03 15:51:18 -05:00

Sign in to join this conversation.