[Due for payment 2026-06-19] [$250] Concierge streaming reply only advances while the browser tab is focused

[melvin-bot]

Platform

Web (any Chromium/Firefox tab-throttling browser)

Problem

When Concierge streams a reply and you switch to another browser tab, the visible text stops advancing. When you return to the tab, it resumes streaming from where it left off — even though the full response was delivered long ago. Streaming should keep up (or complete) regardless of whether the tab is focused.

Root Cause

The Concierge draft pacer reveals the reply one markdown unit per setInterval tick (PUSHER_DRAFT_PACE_INTERVAL_MS = 10ms), and the reveal amount is driven by tick count, not wall-clock time. Browsers throttle/freeze setInterval in backgrounded tabs (Chrome clamps to ≥1000ms after ~1s hidden, effectively freezing timers after ~5 min), so the reveal stalls while hidden and drains rapidly on refocus. The full server text is already buffered over Pusher; only the reveal is gated on the throttled timer.

Key files:

• src/pages/inbox/usePusherDraftPacing.ts — startPusherDraftPace / tickPacing: the setInterval(tickPacing, 10) loop that drives the reveal — one markdown unit per tick, no wall-clock anchor.
• src/pages/inbox/conciergeDraftState.ts — getNextVisibleConciergeDraftMarkdown: advances exactly one unit per call with no time reference.

Contrast with the working path: src/hooks/usePendingConciergeResponse.ts computes progress from Date.now() - trickleStart, so a single throttled tick recomputes the correct wall-clock stage and self-corrects on tab return. The Pusher pacer lacks this anchor.

Suggested Fix

1. Anchor the reveal to wall-clock elapsed time — reveal up to rate × elapsed characters so one post-refocus tick catches up instantly. The optimistic trickle in src/hooks/usePendingConciergeResponse.ts already does this and can serve as a reference.
2. Use @libs/Visibility — listen for visibilitychange: when the tab becomes hidden (or on becoming visible with a completed response already buffered), reveal the full buffered target immediately instead of pacing through it tick by tick.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022063421751747915872
• Upwork Job ID: 2063421751747915872
• Last Price Increase: 2026-06-07

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

The Concierge Pusher draft pacer reveals the streamed reply one markdown unit per setInterval tick, and the amount revealed is gated on tick count, not wall‑clock time.

• The pacer runs setInterval(() => tickPacing(runtime), PUSHER_DRAFT_PACE_INTERVAL_MS) with PUSHER_DRAFT_PACE_INTERVAL_MS = 10 (usePusherDraftPacing.ts:31, :198).
• Each tick advances the visible text by exactly one unit via getNextVisibleConciergeDraftMarkdown — it bumps sourceOffset by one construct per call with no time reference (tickPacing at usePusherDraftPacing.ts:152-189).

Browsers throttle/freeze setInterval in backgrounded tabs (Chrome clamps to ≥1000ms after ~1s hidden, and effectively freezes timers after ~5 min). Because the reveal is driven by tick count, the visible text stalls while hidden and then drains rapidly on refocus. The full server text is already buffered over Pusher — only the reveal is gated on the throttled timer, which is why it "resumes from where it left off" instead of being complete.

Why the optimistic trickle path doesn't have this bug

The optimistic trickle in usePendingConciergeResponse.ts:265-278 computes its stage from elapsed = Date.now() - trickleStart and derives stage = ceil(progress * lastIndex). A single throttled tick after refocus recomputes the correct wall‑clock stage and self‑corrects. The Pusher pacer lacks this anchor.

Alternative explanations considered and ruled out: This is not a Pusher delivery problem (the target bodyMarkdown is fully buffered before the stall) and not a re‑render issue — the gating is purely the tick‑count‑based reveal under a throttled timer.

What changes do you think we should make in order to solve the problem?

1. Anchor the reveal to wall‑clock elapsed time. Track a reveal start timestamp and, on each tick, advance sourceOffset up to rate × elapsed rather than by a fixed one unit per tick. A single post‑refocus tick then catches up to the correct position instantly. usePendingConciergeResponse.ts is a working reference for this pattern.
2. React to tab visibility via @libs/Visibility. Listen for visibilitychange; when the tab becomes hidden, or becomes visible with a completed response already buffered, reveal the full buffered target immediately instead of pacing through it tick by tick.

Either change alone fixes the stall; doing both gives smooth pacing when focused and instant catch‑up on refocus.

What alternative solutions did you explore? (Optional)

A requestAnimationFrame loop would face the same background‑throttling limitation. The wall‑clock anchor is the robust fix because it makes the reveal correct regardless of how often (or how erratically) the timer fires.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92866) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @shubham1206agra (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022063421751747915872

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Web, when Concierge is streaming a reply and the user switches to another browser tab, the visible reply text stops advancing while the tab is hidden and only resumes (slowly draining) after the tab is refocused — even though the full response has already arrived over Pusher. Expected behaviour: the streamed reply should keep advancing (or simply finish) regardless of tab focus, so returning to the tab shows the reply already complete or up to date.

What is the root cause of that problem?

The Pusher draft pacer drives the reveal with a fixed-interval timer in src/pages/inbox/usePusherDraftPacing.ts:198 — setInterval(() => tickPacing(runtime), PUSHER_DRAFT_PACE_INTERVAL_MS) with PUSHER_DRAFT_PACE_INTERVAL_MS = 10 (line 31) — and tickPacing reveals one markdown unit per tick via getNextVisibleConciergeDraftMarkdown with no wall-clock reference. Chromium/Firefox throttle setInterval in hidden tabs (clamped to ≥1s, then frozen), so the per-tick reveal stalls while hidden and only drains one unit per throttled tick on refocus. The optimistic trickle in src/hooks/usePendingConciergeResponse.ts already shows the correct pattern — its tick computes elapsed = Date.now() - trickleStart and derives progress from elapsed wall-clock time (lines 231, 266–267), so a single post-throttle tick self-corrects to the right offset.

What changes do you think we should make in order to solve the problem?

1. In src/pages/inbox/usePusherDraftPacing.ts, add a wall-clock anchor to the pacer runtime (e.g. paceStartTimeRef plus paceStartSourceOffsetRef) set inside startPusherDraftPace (line 191) whenever the pacer (re)starts or a new target snapshot arrives.
2. Change tickPacing (line 152) to advance to targetSourceOffset = paceStartSourceOffset + ceil(rate * (Date.now() - paceStartTime)) characters and loop getNextVisibleConciergeDraftMarkdown until the visible source offset reaches that target (or the target snapshot is exhausted), instead of revealing exactly one unit per tick. Pick rate so the steady-state speed matches today's perceived pace at 10ms/unit.
3. Reset the anchor in setOrQueuePusherDraftTarget / wherever a new pusherTargetBodyMarkdown is committed so each new server snapshot paces from its own start, and clear it on completion (the publishVisibleEvent(..., 'completed') path around line 184).
4. Subscribe to visibilitychange via @libs/Visibility inside usePusherDraftPacing (the hook body around line 439): when the document becomes visible, immediately call tickPacing(runtime) once so the elapsed-time catch-up happens on focus rather than waiting for the next throttled setInterval callback; when it becomes hidden with a completedPusherDraftEventRef/fully-buffered target, fast-forward to the full target so a returning user sees the finished reply.
5. No iOS/Android twin needed — usePusherDraftPacing.ts is shared and the throttling is web-specific, but the wall-clock fix is harmless on native (Date.now() and setInterval work identically there).

What alternative solutions did you explore? (Optional)

Switching setInterval to requestAnimationFrame would also stall when hidden (rAF pauses entirely in background tabs), so it does not fix the bug; a Web Worker timer would dodge throttling but adds cross-thread plumbing for a problem the wall-clock anchor already solves.

[moxw]

Proposal

What is the root cause of that problem?

The Pusher Concierge draft pacer is still driven by interval tick count instead of elapsed wall-clock time.

In src/pages/inbox/usePusherDraftPacing.ts, handlePusherDraftEvent() stores the newest server snapshot in latestPusherDraftEventRef, then calls startPusherDraftPace() for any target that is not fully visible yet. startPusherDraftPace() only starts setInterval(() => tickPacing(runtime), PUSHER_DRAFT_PACE_INTERVAL_MS), and each tickPacing() call advances by calling getNextVisibleConciergeDraftBodyMarkdown() once.

That helper in src/pages/inbox/conciergeDraftState.ts has no time input. It advances by current/target length: one code point for small backlog, ceil(remaining / 40) for larger backlog, and ceil(remaining / 4) for completion acceleration. So progress depends on how many interval callbacks actually ran, not how much time passed.

When the browser tab is hidden, Chromium/Firefox throttle or pause those callbacks. Pusher can still leave the full target buffered in latestPusherDraftEventRef, and completion can be held in completedPusherDraftEventRef, but the visible draft remains behind because pusherPendingCompletionEvent is not cleared until the visible markdown catches pusherTargetBodyMarkdown. This is why returning to the tab resumes from the old visible text instead of showing the already-delivered response.

This is intermittent because short replies, or replies that finish before the tab is hidden, drain normally. It is most visible for long Concierge replies where the tab is backgrounded before the pacer reaches the latest target or before the completed event can be published.

What changes do you think we should make in order to solve the problem?

Add a wall-clock anchor to the Pusher draft pacer in src/pages/inbox/usePusherDraftPacing.ts.

Minimal fix:

1. Track pacing start state in refs, for example:

   • current target body/sequence or stream session
   • visible source length at pacing start
   • paceStartedAtMs
   • completion acceleration state

2. When a new Pusher target is accepted, initialize or reset that anchor from the current visible markdown length and Date.now().

3. In tickPacing(), compute the intended visible source offset from elapsed time, not from one helper call per interval. Then publish the slice up to that offset, preserving the current code-point slicing behavior and the existing “target correction” behavior when the new target no longer starts with the visible text.

4. Preserve the completion behavior, but make it elapsed-time aware: if completedPusherDraftEventRef.current exists and elapsed time has reached the accelerated completion budget, publish the full target with status: 'completed', clear the pending completion ref, and stop the interval.

5. Subscribe with @libs/Visibility.onVisibilityChange() in the hook. On visibility changes, call the catch-up path immediately. If the tab becomes hidden or visible while a completed response is already buffered, publish the full buffered target/completed event immediately instead of waiting for another throttled interval callback.

This matches the safer pattern already used by src/hooks/usePendingConciergeResponse.ts, where progress is recomputed from Date.now() - trickleStart, so a single late callback self-corrects to the right stage.

Verification plan:

• Add unit coverage around tests/unit/pages/inbox/ConciergeDraftContext.test.tsx.
• Mock @libs/Visibility, Date.now(), and timers.
• Emit a long CONCIERGE_DRAFT_UPDATED, let only the initial visible slice render, then simulate elapsed wall-clock time while no interval ticks run.
• Fire the visibility callback or one delayed timer tick and verify the draft jumps to the elapsed-time-correct slice instead of advancing by only one pacing step.
• Add a completed-event case with finalRenderedHTML: after wall-clock completion while hidden, verify getCachedDraft(reportID)?.status becomes completed, pusherPendingCompletionEvent is cleared, and the final HTML/text is applied.
• Manual repro: start a long Concierge reply on web, switch to another browser tab until the reply has finished server-side, then return. The visible reply should already be complete or caught up immediately, not continue draining from the old position.

What alternative solutions did you explore? (Optional)

Using requestAnimationFrame would not fix this because it pauses in hidden tabs. A shorter interval also would not fix it because browsers throttle hidden-tab timers. A worker timer is more complex than needed; the UI only needs to recompute progress from elapsed time whenever the next callback or visibility event arrives.

[innolope-dev]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @innolope-dev Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.