Skip to content

feat(generations): add worker claim and status endpoint#46

Open
Abdulmuiz44 wants to merge 18 commits into
feat/launchpix-api-platform-dashboardfrom
feat/generation-worker-contract-foundation
Open

feat(generations): add worker claim and status endpoint#46
Abdulmuiz44 wants to merge 18 commits into
feat/launchpix-api-platform-dashboardfrom
feat/generation-worker-contract-foundation

Conversation

@Abdulmuiz44

Copy link
Copy Markdown
Collaborator

Summary

Day 12 / PR 2 of the async generation migration plan.

Adds safe primitives for a future async worker without changing generation execution behavior.

What changed

Worker claim helper (lib/services/generations/claim.ts)

  • claimGenerationForProcessing({ supabase, generationId, workerId? })
  • Conditional update: only claims when status = "queued"
  • Transitions to analyzing on success
  • Returns { claimed: true, generation } or { claimed: false, reason }
  • Reasons: not_found, terminal, in_progress, not_claimable
  • Two workers cannot claim the same generation (conditional Postgres update)

Generation status contract (lib/services/generations/status.ts)

  • Shared status types: draft, queued, analyzing, generating_copy, rendering_assets, completed, failed
  • Helpers: isTerminalGenerationStatus, isClaimableGenerationStatus, getGenerationPhase
  • Public polling response mapper: mapGenerationToPublicStatus
  • Does not expose ai_summary, copy_json, or raw style_json

GET by generation id

  • GET /api/v1/projects/[projectId]/generations/[generationId]
  • Same auth as existing generate routes (x-launchpix-api-key, x-launchpix-user-id)
  • Verifies project ownership, scopes lookup to projectId + generationId
  • Returns polling-friendly payload with status, phase, assets, downloadUrl, error

Query helper

  • getGenerationForProject(projectId, generationId) in queries.ts

Intentionally not included

  • No async jobs / worker loop
  • No queue / enqueue
  • No 202 Accepted on POST /generate
  • No billing changes
  • No changes to synchronous runGenerationForProject behavior
  • Existing GET /api/v1/projects/[projectId]/generate (latest generation) unchanged

Validation

Check Result
npm run typecheck Pass
npm run build Pass (includes new route)
npm test Pass — 11 tests

Next step

Day 13: POST returns 202 + enqueue. Day 14: worker executes using Day 11 modules + Day 12 claim/status contract.

Test and others added 18 commits June 9, 2026 02:14
Implement billing verification state
Day 12 / PR 2 of async migration foundation:
- generation status contract and public response mapper
- conditional worker claim helper (queued -> analyzing)
- GET /api/v1/projects/[projectId]/generations/[generationId]
- unit tests for claim, status mapping, and project scoping

No async execution, queue, or 202 response changes.
Day 13 / PR 3 of async migration: POST /generate returns 202 Accepted
with generationId, queued status, and poll URL. Durable enqueue via
generations row + usage_events audit trail. No worker execution yet.
Create async submissions as draft, consume credit, then promote to
queued and mark the project queued before enqueue returns 202.
Prevents workers from claiming unpaid generations and keeps project
list status aligned with accepted jobs.
feat(generations): enqueue generation requests
Keep split generation runner modules and integrate main logging.
Fix docs typed-route links and align generate API docs with 202 enqueue.
Addresses Codex P1 on PR #48: async 202 acceptance no longer ships without
a runtime processor. v1 POST runs runGenerationForProject (201) by default;
LAUNCHPIX_ASYNC_GENERATION enables 202 enqueue with claim-based worker via
POST /api/internal/worker/generations/process or inline when configured.
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