Skip to content

feat(recall): inspect extraction progress - #1332

Open
wesm wants to merge 3 commits into
mainfrom
feat/recall-progress
Open

feat(recall): inspect extraction progress#1332
wesm wants to merge 3 commits into
mainfrom
feat/recall-progress

Conversation

@wesm

@wesm wesm commented Aug 1, 2026

Copy link
Copy Markdown
Member

Recall’s aggregate coverage counts do not identify which sessions are blocked or explain extraction failures. This adds a read-only progress drilldown to the Recall page with generation-scoped pending, partial, and failed rows, source-session links, unit progress, error details, retry timing, localized state filters, and bounded cursor pagination.

The endpoint reads directly from persisted extraction state, so existing archives remain inspectable without a configured extraction manager. The surface deliberately excludes retry, run, activation, and retirement actions; those model-work and corpus-lifecycle controls remain separate follow-ups.

Aggregate coverage counts do not explain which sessions are blocked or why, forcing operators back to database inspection when extraction stalls. Expose a bounded, generation-scoped progress view so pending, partial, and failed work can be diagnosed from the Recall page without loading transcripts or enabling the extraction manager.

The surface is intentionally read-only. Retry and generation lifecycle mutations remain separate follow-ups so this diagnostic contract can land without introducing model-work controls.
@roborev-ci

roborev-ci Bot commented Aug 1, 2026

Copy link
Copy Markdown

roborev: Combined Review (4844546)

The PR is generally sound, but one medium-severity backend compatibility issue should be addressed.

Medium

  • internal/server/recall.go:446 — The progress query bypasses the shared store contract through an optional interface, so PostgreSQL-backed pg serve always returns HTTP 501 while the Recall page still displays “Show progress.” Add the query to db.Store with PostgreSQL parity, or expose backend capability and hide or disable the progress control when unavailable.

Reviewers: 2 done | Synthesis: codex, 6s | Total: 6m26s

Recall extraction progress depends on archive-owned state that read-only backends do not provide. Advertising the drill-down unconditionally leaves those deployments with a control that can only return HTTP 501.\n\nExpose the capability through the existing status response so clients can omit unsupported controls while preserving progress inspection for local SQLite archives.
@roborev-ci

roborev-ci Bot commented Aug 2, 2026

Copy link
Copy Markdown

roborev: Combined Review (9a015b2)

One medium-severity issue should be fixed before merging.

Medium

  • frontend/src/lib/components/recall/RecallPage.svelte:251 — Hiding the panel aborts the current request but does not clear progressLoading, because the aborted request’s finally cannot finish a canceled LatestRead. The page-level refresh control can remain busy indefinitely until progress is reopened. Clear progressLoading when canceling the request, or include it in the refresh busy state only while the panel is expanded.

Reviewers: 2 done | Synthesis: codex, 7s | Total: 4m55s

The progress panel owns a request whose cancellation invalidates its completion callback. Leaving its loading flag set keeps the page-level refresh action disabled even though the panel and its work are gone.\n\nReset the loading state alongside cancellation so closing the drill-down immediately restores the rest of the page controls.
@roborev-ci

roborev-ci Bot commented Aug 2, 2026

Copy link
Copy Markdown

roborev: Combined Review (f6f4d79)

No issues found.


Reviewers: 2 done | Synthesis: codex | Total: 5m36s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant