feat: add podcast episode unit economics - #276
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 20221dcb3e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| .select('id,pipeline,episode_id,status,started_at') | ||
| .not('episode_id', 'is', null) | ||
| .order('started_at', { ascending: false }) | ||
| .limit(RUN_LIMIT); |
There was a problem hiding this comment.
Aggregate all runs for each displayed episode
When an older episode receives a recent render or retry, it enters this result set even though its ingest and earlier render runs may fall outside the global newest-200 cutoff. The response then presents the resulting subtotal as that episode's total unit cost, silently understating podcast cost, retry waste, and run counts; select the displayed episode IDs first and retrieve their complete run histories, or otherwise indicate that the values are partial.
Useful? React with 👍 / 👎.
| 'run_id,episode_id,language_code,stage,status,estimated_cost_usd,pricing_basis', | ||
| ) | ||
| .in('run_id', runIds) | ||
| .limit(2_000), |
There was a problem hiding this comment.
Paginate all stage rows before summing costs
When the selected 200 runs contain more than 2,000 stage rows, this query returns only a subset, without an ordering or truncation signal. summarizePodcastCosts consequently reports incomplete totals, breakdowns, and unpriced-operation counts as authoritative values; paginate the stage query or aggregate the complete set in the database.
Useful? React with 👍 / 👎.
| episodeId: job.episode_id, | ||
| runRef: context.runId, | ||
| attempt: job.attempt_count, | ||
| status: 'completed', |
There was a problem hiding this comment.
Mark the visual run complete only after persistence
When visual processing returns but visualRepository.complete(...) later fails, loses the lease, or is skipped because shutdown aborts the context, this wrapper has already recorded the attempt as completed. The worker then treats the same attempt as failed and retries it, but the dashboard excludes its spent compute from retry waste and reports a completed run; record the outcome at the claimed-job lifecycle boundary after the repository completion succeeds.
Useful? React with 👍 / 👎.
Summary
ops.pipeline_*ledgerCost semantics
Tests
No new infrastructure or Sentry heartbeat/uptime accounting is introduced.