[$250] Agent Zero status indicator gets stuck until page refresh

[MelvinBot]

Spun off from Expensify/Expensify#599556 per marcaaron's request.

Problem

In a Concierge chat, the user-facing "Concierge is thinking..." / "Concierge is waiting for you to finish..." status indicator can get stuck and not clear until the user refreshes the page.

The useAgentZeroStatusIndicator() hook sets an optimistic "Concierge is waiting for you to finish..." label when the user sends a message. If the Pusher updates carrying the intermediate/clearing labels are dropped, the optimistic label stays stuck until a refresh.

The server-side clearing mechanisms are confirmed to be working correctly (the indicator clears after a page refresh, confirming DB state is correct). The issue is on the client side — the real-time Onyx push update is being missed.

Expected Behavior

The typing/status indicator should reliably clear without requiring a page refresh.

Debugging Info

• Example chat/reportID: 61393108
• Current indicator hook reference:

  App/src/hooks/useAgentZeroStatusIndicator.ts

  Line 10 in 75478c5

  const WAITING_LABEL = 'Concierge is waiting for you to finish...';

• Observed behavior from logs: Server did set the value that clears the indicator, but client likely missed the Pusher/Onyx update (indicator cleared after refresh, implying DB state was correct).
• Log search (AgentZero request): https://www.expensify.com/_devportal/tools/logSearch/#sort=asc&size=10000&query=(%22agentZeroRequestID_kVDrBA%22)%20timestamp%3A%5B2026-02-11T00%3A00%20TO%202026-02-12T23%3A59%5D&engine=victorialogs

Investigation Notes (from Expensify/Expensify#599556)

Server-side clearing (confirmed working — 3 layers of redundancy):

1. Auth C++ finalizeResponse() calls emitConciergeStatus(reportID, "", true) → UpdateConciergeStatus PHP API
2. PHP main flow clearUserFacingIndicator() → Auth::setReportNameValuePair() → generates Onyx update
3. PHP finally block safety net → same Auth::setReportNameValuePair() path

Client-side (suspected problem area):

• The agentZeroProcessingRequestIndicator rNVP IS included in the reliable Onyx updates system (clients can catch up on missed updates via GetOnyxUpdates)
• The useAgentZeroStatusIndicator() hook sets an optimistic label when the user sends a message — if Pusher updates are dropped, this optimistic label gets stuck
• There is no polling/reconciliation mechanism for this specific indicator
• A possible fix: add a client-side timeout to clear the indicator if no update is received within a reasonable window

Potential Solutions

• Investigate why the Onyx update clearing the indicator is being missed by the client
• Consider adding a timeout-based fallback in useAgentZeroStatusIndicator to clear the stuck indicator after a reasonable duration
• Investigate if there is a Pusher reliability issue or an Onyx re-sync gap for this specific rNVP

Issue Owner

Current Issue Owner: @QichenZhu

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022027538040479794626
• Upwork Job ID: 2027538040479794626
• Last Price Increase: 2026-02-28

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @lydiabarclay (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

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

[MelvinBot]

Proposal

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

In a Concierge chat, the "Concierge is waiting for you to finish..." status indicator can get permanently stuck and never clear until the user refreshes the page. The server-side clearing mechanisms work correctly (confirmed by the indicator clearing on refresh), so the problem is entirely client-side.

What is the root cause of that problem?

The clearing effect in useAgentZeroStatusIndicator has a logical flaw — it requires serverLabel to be truthy before it will clear the optimistic label:

// Line 179-187
useEffect(() => {
    const hasServerUpdatedSinceKickoff = waitingSessionVersion !== null && serverLabelVersion !== waitingSessionVersion;
    if (!serverLabel || !hasServerUpdatedSinceKickoff) {
        return; // ← returns early when serverLabel is falsy
    }
    setOptimisticLabel(undefined);
    setWaitingSessionVersion(null);
}, [serverLabel, serverLabelVersion, waitingSessionVersion]);

The intended flow is:

1. User sends a message → kickoffWaitingIndicator() sets optimisticLabel to "Concierge is waiting for you to finish..."
2. Server sets a real label (e.g., "Concierge is thinking...") → Pusher delivers → serverLabel becomes truthy → clearing effect fires → optimistic label cleared
3. Server clears the label → serverLabel becomes "" (falsy) → display effect clears the UI

The bug: If Pusher drops the intermediate "set" update (step 2) and only the final "clear" (empty string) arrives — or if both updates are missed entirely — then serverLabel stays falsy ("".trim() is ""). The clearing effect's !serverLabel guard causes an early return, so optimisticLabel is never cleared. The display effect at line 197 sees optimisticLabel is still set and keeps showing it indefinitely.

There is also a secondary stuck scenario: if Pusher delivers the "set" but drops the "clear," the filler message loop at line 215-234 runs indefinitely since it has no timeout either.

No timeout or fallback mechanism exists anywhere in the hook for either scenario.

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

Two changes in src/hooks/useAgentZeroStatusIndicator.ts:

1. Fix the clearing effect logic (lines 179-187): Remove the !serverLabel guard so the effect clears optimisticLabel whenever the server has responded in any way (including clearing to empty). Change:

if (!serverLabel || !hasServerUpdatedSinceKickoff) return;

to:

if (!hasServerUpdatedSinceKickoff) return;

This way, when reportNameValuePairs updates after kickoff (whether the indicator was set and cleared, or only cleared), the optimistic label is properly cleared.

2. Add a safety timeout as defense-in-depth: After the optimistic label is set, start a timeout (e.g., 60 seconds). If no server update has cleared the optimistic label by then, force-clear it. This covers any remaining edge cases where Pusher and Onyx catch-up both fail entirely. Similarly, the filler message display effect should have a maximum lifetime to handle the case where the server "clear" update is missed.

What alternative solutions did you explore? (Optional)

• Track indicator-specific version instead of the entire reportNameValuePairs object: The current serverLabelVersion increments on ANY change to reportNameValuePairs (not just agentZeroProcessingRequestIndicator), which could cause false version increments from unrelated NVP field changes. A more precise approach would track only the agentZeroProcessingRequestIndicator value. However, the simpler fix (removing the !serverLabel guard) resolves the bug without adding this complexity — an unrelated NVP change clearing the optimistic label slightly early is far less bad than it getting permanently stuck.
• Server-side workaround: Have the server transition through a "done" label instead of clearing directly to empty string. Rejected because it adds unnecessary server complexity and the bug should be fixed where it lives (client-side).

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[lucabarak]

Proposal

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

The "Concierge is waiting for you to finish..." optimistic label gets stuck and never clears until page refresh. The server-side clearing works correctly (confirmed by indicator clearing on refresh), so the issue is entirely client-side.

What is the root cause of that problem?

The clearing effect in useAgentZeroStatusIndicator.ts (line 179-187) requires serverLabel to be truthy before it clears the optimistic state:

if (!serverLabel || !hasServerUpdatedSinceKickoff) {
    return;
}

When Pusher drops the intermediate "set" update and only the final "clear" (empty string) arrives, serverLabel is falsy ("".trim() → ""). The !serverLabel guard returns early, so optimisticLabel is never cleared. The display effect then sees optimisticLabel is still set and keeps showing it indefinitely.

Secondary stuck scenario: if Pusher delivers the "set" but drops the "clear," the scheduleNextFiller loop (line 215+) runs indefinitely with no upper bound.

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

Three changes in src/hooks/useAgentZeroStatusIndicator.ts:

1. Fix the clearing effect guard (line 181):

Change:

if (!serverLabel || !hasServerUpdatedSinceKickoff) {
    return;
}

To:

if (!hasServerUpdatedSinceKickoff) {
    return;
}

This allows the clearing effect to fire when reportNameValuePairs updates after kickoff, regardless of whether serverLabel is truthy or empty. When the server clears the indicator (empty string), the version still increments, so hasServerUpdatedSinceKickoff becomes true and the optimistic label gets properly cleared.

2. Add a safety timeout in kickoffWaitingIndicator:

After setting optimisticLabel, start a 60-second timeout that force-clears it if no server update has arrived. This handles the edge case where both Pusher and Onyx catch-up fail entirely.

3. Add max lifetime to the filler message loop:

The scheduleNextFiller loop has no upper bound — if the server "clear" update is missed, it cycles filler messages forever. Add a max duration (e.g., 120 seconds) after which it stops and clears the display label.

What alternative solutions did you explore? (Optional)

• Tracking only the agentZeroProcessingRequestIndicator value instead of the full reportNameValuePairs object for version changes: More precise but adds complexity. The simpler guard fix resolves the core bug — an unrelated NVP change clearing the optimistic label slightly early is far preferable to it getting permanently stuck.
• Server-side transition through a "done" label instead of clearing to empty string: Rejected because the bug is client-side and should be fixed where it lives.

[melvin-bot]

📣 @lucabarak! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[lucabarak]

Contributor details
Your Expensify account email: barakluca@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0111f9dd1f109a3d5a

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!