fix(web): keep progress chips visible for a minimum duration - #219
fix(web): keep progress chips visible for a minimum duration#219deepanshu1422 wants to merge 3 commits into
Conversation
A fast tool call (e.g. schedule_create) can complete before the browser gets a paint frame, so the terminal event immediately strips the live "working…" chip from the thread — the intermediate progress never actually renders, even though the run did real work. Track when a progress/steps message is first seen, and delay applying its terminal event until it's been visible for at least 700ms if it ever painted anything. The first-seen map is capped so a message whose terminal event never reaches this client doesn't linger forever. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
|
Warning Review limit reachedNext included review available in 18 minutes. View limit detailsLimit details: You’ve used all 4 included reviews currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThe PR keeps transient progress chips visible for a minimum duration without delaying terminal run-state updates or blocking the event stream.
|
| Filename | Overview |
|---|---|
| apps/web/src/lib/thread-events.ts | Adds bounded first-seen tracking and snapshot reconciliation that temporarily retains visible progress messages. |
| apps/web/src/pages/Shell.tsx | Integrates delayed progress removal into snapshot commits and cleans timers across lifecycle transitions. |
| apps/web/src/lib/thread-events.test.ts | Adds focused coverage for progress retention across terminal events, refreshes, waiting-input states, and thread clears. |
Reviews (3): Last reviewed commit: "chore: retrigger CI after transient acti..." | Re-trigger Greptile
Playwright screenshotsOpen screenshot gallery · Dashboard · CI run Updated for commit |
Keep the 700ms min-visible chip by retaining live progress removal in commitSnapshot/retainMinVisibleLiveProgress instead of awaiting inside the subscribe loops. Terminal events, durable answers, and refreshes apply on time; only the live chip strip is deferred. Stop and waiting_input still clear immediately. Co-authored-by: Elie Steinbock <elie222@users.noreply.github.com>
Lint and Postgres journeys failed at Set up job downloading pnpm/action-setup (DNS), not on our changes. Retrigger the suite. Co-authored-by: Elie Steinbock <elie222@users.noreply.github.com>
|
Hey, why does the user need to see in the progress state if it's already done? |
3 participants
Summary
A fast tool call (e.g.
schedule_create) can complete before the browsergets a paint frame, so the terminal event immediately strips the live
"working…" chip from the thread — the intermediate progress never actually
renders, even though the run did real work.
Changes
progressFirstSeenRef)for at least 700ms, but only if it ever actually rendered something
event never reaches this client (SSE drop mid-run, tab backgrounded
through a reconnect, bot archived mid-run) doesn't linger forever
Testing notes
pnpm --filter @rakazo/web checkbiome checkon the touched file