[Frontend] Give async operations an elapsed timer and an expected duration #381

Closed
opened 2026-08-25 20:42:19 +00:00 by claude-bot · 2 comments
Contributor

Impact: MEDIUM

Found in the August 2026 session lifecycle review (#319).

What the user experiences

Whenever the product says "Processing…" or "Generating…", that is the entire signal. There is no elapsed time, no ETA, and no sense of whether the operation is on track or stuck. The workbench's async generation is worse still: the only feedback is the button label flipping to "Generating…" with no spinner, and after 60 seconds it says "This is taking longer than expected — check the history rail shortly" — "history rail" being internal vocabulary that appears nowhere else in the UI, and (per the companion Workbench issue) the panel it points to doesn't refresh anyway.

Evidence

  • webapp/frontend/src/pages/SessionDetail.jsx:93 and webapp/frontend/src/pages/RecordingDashboard.jsx:36 — status pills read "Processing…" with no elapsed time or ETA.
  • webapp/frontend/src/components/GeneratorPanel.jsx:367-373 — button label flips to "Generating…"; no spinner, no elapsed time, no ETA.
  • webapp/frontend/src/components/GeneratorPanel.jsx:261 — the timeout message references "the history rail", a term the rest of the UI calls "Generation History" (GenerationHistory.jsx:74).

Why it matters for a hosted product

This is cheap to add and is the difference between "working" and "broken" in a user's head during any LLM- or transcription-backed wait, which in this product can run from seconds to several minutes.

Proposed fix

Everywhere a status says "Processing…" or "Generating…", add an elapsed-time counter and a typical-duration hint (e.g. "usually 2–5 minutes for a 3-hour session"). Replace "history rail" with "Generation History" to match the actual panel name. This is the audit's P10.

Acceptance criteria

  • SessionDetail's processing status pill shows elapsed time while processing.
  • RecordingDashboard shows elapsed time and a typical-duration hint during transcription/summarisation.
  • The workbench's "Generating…" state shows elapsed time.
  • The workbench timeout message refers to "Generation History", matching the panel's actual name.
**Impact: MEDIUM** Found in the August 2026 session lifecycle review (#319). ## What the user experiences Whenever the product says "Processing…" or "Generating…", that is the entire signal. There is no elapsed time, no ETA, and no sense of whether the operation is on track or stuck. The workbench's async generation is worse still: the only feedback is the button label flipping to "Generating…" with no spinner, and after 60 seconds it says "This is taking longer than expected — check the history rail shortly" — "history rail" being internal vocabulary that appears nowhere else in the UI, and (per the companion Workbench issue) the panel it points to doesn't refresh anyway. ## Evidence - `webapp/frontend/src/pages/SessionDetail.jsx:93` and `webapp/frontend/src/pages/RecordingDashboard.jsx:36` — status pills read "Processing…" with no elapsed time or ETA. - `webapp/frontend/src/components/GeneratorPanel.jsx:367-373` — button label flips to "Generating…"; no spinner, no elapsed time, no ETA. - `webapp/frontend/src/components/GeneratorPanel.jsx:261` — the timeout message references "the history rail", a term the rest of the UI calls "Generation History" (`GenerationHistory.jsx:74`). ## Why it matters for a hosted product This is cheap to add and is the difference between "working" and "broken" in a user's head during any LLM- or transcription-backed wait, which in this product can run from seconds to several minutes. ## Proposed fix Everywhere a status says "Processing…" or "Generating…", add an elapsed-time counter and a typical-duration hint (e.g. "usually 2–5 minutes for a 3-hour session"). Replace "history rail" with "Generation History" to match the actual panel name. This is the audit's P10. ## Acceptance criteria - [ ] `SessionDetail`'s processing status pill shows elapsed time while processing. - [ ] `RecordingDashboard` shows elapsed time and a typical-duration hint during transcription/summarisation. - [ ] The workbench's "Generating…" state shows elapsed time. - [ ] The workbench timeout message refers to "Generation History", matching the panel's actual name.
Author
Contributor

Picking this up as v4.3.0 phase 3 (#514), last on the Prep lane since the generator panel is already open there. Elapsed-time counters and a typical-duration hint on every "Processing…" and "Generating…" state, and the timeout message names "Generation History" instead of the internal "history rail".

Picking this up as v4.3.0 phase 3 (#514), last on the Prep lane since the generator panel is already open there. Elapsed-time counters and a typical-duration hint on every "Processing…" and "Generating…" state, and the timeout message names "Generation History" instead of the internal "history rail".
Author
Contributor

Done in the phase 3 PR (auto-merging on green); ships with v4.3.0.

One ElapsedTimer for the session page's audio status, the recording page and the Prep tool button, the same component in all three, because two screens describing the same pipeline must not quote different numbers at the same GM. Each shows time elapsed plus what normal looks like; the second half is where the information actually is, since a rising number alone does not tell anyone whether four minutes is fine.

One honest limitation. The audio pipeline records no start time on the session, so the timer anchors on updated_at: the pipeline sets the status when it takes the job and nothing else writes while it runs. An unrelated edit to the session resets it, so this can under-report; it never over-reports, which is the safe direction for a number a GM reads as "should I retry yet?". An audio_processing_started_at column would make it exact, but that is a migration and outside this issue.

The hints are typical, not measured, and the code says so: a deployment's real figure is on Admin → AI (extrapolated from that install's own recent runs) and per-run queue estimates already arrive as processing_wait. What belongs beside a spinner is an honest order of magnitude, not a precise number that is wrong on someone else's hardware.

"the history rail" is gone; the overrun message names Generation History, which is what the panel beside it is called. Tests cover the formatter (never negative), the tick, the mount fallback, unmount cleanup, the copy, and the timer appearing on the session and recording pages only while processing.

Done in the phase 3 PR (auto-merging on green); ships with v4.3.0. One `ElapsedTimer` for the session page's audio status, the recording page and the Prep tool button, the same component in all three, because two screens describing the same pipeline must not quote different numbers at the same GM. Each shows time elapsed plus what normal looks like; the second half is where the information actually is, since a rising number alone does not tell anyone whether four minutes is fine. One honest limitation. **The audio pipeline records no start time on the session**, so the timer anchors on `updated_at`: the pipeline sets the status when it takes the job and nothing else writes while it runs. An unrelated edit to the session resets it, so this can under-report; it never over-reports, which is the safe direction for a number a GM reads as "should I retry yet?". An `audio_processing_started_at` column would make it exact, but that is a migration and outside this issue. The hints are typical, not measured, and the code says so: a deployment's real figure is on Admin → AI (extrapolated from that install's own recent runs) and per-run queue estimates already arrive as `processing_wait`. What belongs beside a spinner is an honest order of magnitude, not a precise number that is wrong on someone else's hardware. "the history rail" is gone; the overrun message names **Generation History**, which is what the panel beside it is called. Tests cover the formatter (never negative), the tick, the mount fallback, unmount cleanup, the copy, and the timer appearing on the session and recording pages only while processing.
Sign in to join this conversation.
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
rbrooks/Quest-Board#381
No description provided.