admin: run AI generation as background jobs to avoid proxy timeouts #94

New Issue

2026-09-30T03:04:51Z

eleith commented

2026-09-30 03:04:51 +00:00

Problem

Admin create & generate and generate for an existing piece run synchronously in one HTTP form request. Every reverse proxy in front of the app needs a long read timeout; an outer proxy left at its default can still return a 504 before Luzzle responds. Refreshing or disconnecting also loses the result of in-flight generation. #93 extends the inner proxy timeout and sets a bounded SDK request timeout, but does not remove this architectural limitation.

Desired behavior

Run generation in the background using the web stack's existing worker/job infrastructure. Return promptly with a job identifier, show pending/running/succeeded/failed status in the admin UI, and persist the result so the user can return after a refresh or disconnect. Show a useful failure reason and allow retry without duplicate piece creation. Keep generated metadata reviewable before the user saves it; a failed create-and-generate job must not create a piece (as in #77).

Acceptance direction

Both admin generation flows can complete beyond the default proxy read timeout without holding an HTTP request open.
Status and the generated draft or error remain accessible after reconnecting; failures are visible and retryable.
Existing pieces are unchanged until review/save, and create retries do not overwrite another piece.
Cover success, failure, reconnect, and retry paths with tests.

Related: #77 (generation error UX), #93 (bounded synchronous timeouts). This is a larger architectural enhancement, not part of the one-commit issue batch.

## Problem Admin **create & generate** and **generate for an existing piece** run synchronously in one HTTP form request. Every reverse proxy in front of the app needs a long read timeout; an outer proxy left at its default can still return a 504 before Luzzle responds. Refreshing or disconnecting also loses the result of in-flight generation. #93 extends the inner proxy timeout and sets a bounded SDK request timeout, but does not remove this architectural limitation. ## Desired behavior Run generation in the background using the web stack's existing worker/job infrastructure. Return promptly with a job identifier, show pending/running/succeeded/failed status in the admin UI, and persist the result so the user can return after a refresh or disconnect. Show a useful failure reason and allow retry without duplicate piece creation. Keep generated metadata reviewable before the user saves it; a failed create-and-generate job must not create a piece (as in #77). ## Acceptance direction - Both admin generation flows can complete beyond the default proxy read timeout without holding an HTTP request open. - Status and the generated draft or error remain accessible after reconnecting; failures are visible and retryable. - Existing pieces are unchanged until review/save, and create retries do not overwrite another piece. - Cover success, failure, reconnect, and retry paths with tests. Related: #77 (generation error UX), #93 (bounded synchronous timeouts). This is a larger architectural enhancement, not part of the one-commit issue batch.

eleith added the enhancement label 2026-09-30 03:04:51 +00:00

eleith referenced this issue

2026-10-01 15:30:14 +00:00

Add safe piece creation and validated LLM generation #95

eleith commented

2026-10-03 15:13:24 +00:00

background jobs come with a lot more weight because data would be passed through storage (sqlite). what we actually wanted was streaming (SSE) so we can avoid nginx timeouts and having to manually specify timeout limits. this will be addressed by #95 #96 and #97

eleith closed this issue

2026-10-03 15:21:48 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: eleith/luzzle#94