[builtbyrishabh]

Refs #16

User-facing problem

Refreshing a queued, generating, or failed job lost meaningful state because realtime was treated as truth. Terminal writers used different refund identities and could expose inconsistent lifecycle behavior.

Implementation summary

• Persist current stage, safe/internal errors, retryability, generating/completed/failed/refunded timestamps, and updated status metadata.
• Deterministically backfill existing jobs, including recognition of legacy refund ledger identities.
• Centralize queued→generating, generating→complete, queued/generating→failed, stage updates, and terminal refund behavior.
• Use one canonical ${jobId}_terminal_refund identity and conditional status updates so only one competing terminal path can refund.
• Route dispatch failure, Inngest terminal failure, and final completion through the lifecycle module.
• Add owner-scoped getStatus returning safe fields only; internal diagnostics never enter the API response.
• Emit completed/error events on the subscribed job channel.
• Refactor the job page around persisted initial state, controlled polling, reconnect/window refetch, and realtime-triggered durable refetch.
• Prevent concurrent create retries from dispatching duplicate Inngest events.

Migration notes

0018_equal_bullseye.sql adds lifecycle columns and backfills stage/timestamps/errors/retryability/refund state from existing jobs and credit transactions. No production migration was run.

Security and financial invariants

Status lookup includes job ID and authenticated owner ID. Terminal state updates require an expected nonterminal prior state. Complete and failed are terminal. A terminal transition and refund share one transaction, and the ledger source ID is canonical and unique. Raw diagnostics remain server-only.

Tests run

• PASS: pnpm test (17 tests, including every allowed/rejected transition and canonical refund identity)
• PASS: pnpm typecheck
• PASS: pnpm lint with non-secret production placeholders
• PASS: pnpm format:check
• PASS: git diff --check
• PASS: production pnpm build (18 routes)

Checks not run and why

• NOT RUN: database integration tests for concurrent terminal paths; no isolated PostgreSQL test database is configured. Conditional predicates, transaction boundaries, and unique ledger identity were statically verified.
• NOT RUN: two-account Clerk status access; no second authenticated test session was used.
• NOT RUN: live realtime disconnect/reconnect simulation; polling/reconnect settings were verified in code.
• NOT RUN: production migration/deployment.

Stack dependency and merge order

Stack PR 4 of 5. Base: launch/15-config-ci. Merge #13, #14, #15, #16, then #19.

Known limitations

Partial preview state remains realtime-only; durable recovery guarantees lifecycle/status and the final manifest, not every intermediate frame. Retry execution itself remains future issue #17; this PR records whether failure is retryable.

Rollback implications

Revert the UI/API writers before dropping lifecycle columns. Dropping them discards diagnostic/timestamp history; credit ledger refunds remain durable and should never be reversed by schema rollback.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
anime-room	Ready	Preview, Comment	Jul 17, 2026 2:46pm

[coderabbitai]

Warning

Review limit reached

@D33ADLOCK, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 48 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Free

Run ID: 6514a681-ba09-46a4-a5b3-cedea4f3248e

📥 Commits

Reviewing files that changed from the base of the PR and between 2f09378 and 2aba186.

📒 Files selected for processing (15)

• drizzle/0018_equal_bullseye.sql
• drizzle/meta/0018_snapshot.json
• drizzle/meta/_journal.json
• src/app/(dashboard)/videos/[jobId]/livePlayer.tsx
• src/app/(dashboard)/videos/[jobId]/page.tsx
• src/inngest/finalisePipeline.ts
• src/inngest/functions.ts
• src/lib/realtime/job-event.ts
• src/lib/realtime/safeRealtimeEmit.ts
• src/server/api/routers/job.ts
• src/server/db/schema.ts
• src/server/jobs/jobLifecycle.test.ts
• src/server/jobs/jobLifecycle.ts
• src/server/jobs/jobTransitions.ts
• vitest.config.ts

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login.

_{Comment @coderabbitai help to get the list of available commands.}