[richiemcilroy]

The finalize-stale-desktop-segments cron has a legacy pass for segmented desktop recordings that never got a processing job, usually because the app's recording-complete call never arrived. Each run takes the oldest eligible rows (updatedAt ASC, 5 to 20 of them) and finalizes any whose segment manifest is complete.

Instant recordings that never captured anything also sit in that window. Their rows never change: no manifest, no write-back, and the same updatedAt on every run. So they hold the front of the queue for their whole 7 days, and a recording that does have a finished manifest is only reached in the last hours before it would leave the window.

flowchart LR
    W["Eligible legacy rows<br/>1 hour to 7 days old"] --> O["Oldest first<br/>every remaining slot, as before"]
    W --> N["Newest first<br/>up to 5 more"]
    O --> U[Oldest rows, then newest rows not already picked]
    N --> U
    U --> C[Check each manifest, as before]

Loading

• The legacy pass keeps its oldest-first query exactly as it was, with every remaining slot, so its coverage before rows leave the window is unchanged (apps/web/lib/desktop-segments-recovery.ts:295).
• It then checks up to 5 of the newest eligible rows that the oldest-first query did not pick (DESKTOP_SEGMENTS_LEGACY_NEWEST_BATCH_SIZE), so a recording is checked within one run of qualifying.
• The per-row checks, the durable job pass and the query's filters are unchanged. There are no new database writes, no schema change and nothing users can see. A run checks at most 5 more rows.

Simulation

desktop-segments-recovery.test.ts adds a simulation of a day of 15-minute runs over 8 days of never-changing empty rows, with one stuck recording that has a finished manifest. It asserts:

• the stuck recording is queued within one run of qualifying;
• every row that ages out during the day is checked first;
• every row that qualifies during the day is checked within one run.

A second simulation keeps the durable pass full, so only 5 legacy slots remain, and adds a burst of rows that start together, one of them a finished recording. The finished recording must still be reached before it ages out.

Against the previous query the stuck recording is never reached during the day; giving the newest rows some of the oldest-first slots instead would miss the recording in the burst.

Confidence Score: 5/5

The PR appears safe to merge; the update preserves oldest-first coverage while checking newer recordings too.

Summary

The update preserves every oldest-first recovery slot and adds up to five newest eligible recordings, skipping duplicates.

• The recovery cron checks newly eligible recordings sooner.

_{Reviews (3) · Last reviewed commit: "test(web): reach a finished recording in..." · Reviewed by Greptile}

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated
cap-status	Skipped		Oct 24, 2026 2:51pm UTC

[richiemcilroy]

hey @greptileai, please re-review the PR

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.

[richiemcilroy]

hey @greptileai, please re-review the PR