Android - Show history button is not displayed in Concierge chat

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.45-1
Reproducible in staging?: Yes
Reproducible in production?: Unable to validate in Prod - Provide reasoning.
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94814
Email or phone of affected tester (no customers): gocemate+ddfdfj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: samsung galaxy a34/16
App Component: Other

Action Performed:

Precondition: the test account has a previous chat history with Concierge.

Steps:

1. Open the app and navigate to any conversation or workspace chat
2. Click the search icon in the top right corner
3. Type a query intended for Concierge (e.g. "How to connect QBD")
4. Click "Ask Concierge" shown below the search input results
5. Verify the side panel shows the just-sent question with "Concierge is thinking…" underneath it
6. Wait until the reply arrives and verify the question + reply stay visible (the panel does NOT collapse to "Hi there, how can I help?")

Expected Result:

Concierge history should remain hidden until "Show history" is clicked

Actual Result:

Concierge history is not hidden, no "Show history" button

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7219136_1785181852242.Recording__1269.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7219136

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081979043700095149
• Upwork Job ID: 2081979043700095149
• Last Price Increase: 2026-07-28

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/b46c62e2de4cf19492d98c3670b236d554b7b710befaf9ca1146ec74ebfe13cd

[MelvinBot]

Proposal

This is a QA regression of the merged PR #94814 (fix for #90974). That PR made the Concierge "hidden history" feature work correctly on the side panel, but the exact same flow on Android native goes through a different code path that still breaks.

What is the root cause of that problem?

On Android native there is no Concierge side panel (isSidePanelReportSupported/index.native.ts:3 is false), so "Ask Concierge" from search opens the main Concierge DM instead (useOpenConciergeAnywhere/index.native.tsx:22-26 → navigateToConciergeChat, isInSidePanel: false). That makes isConciergeMainDM = true.

Whether history is hidden and whether the "Show history" button shows both hinge on hadUserMessageAtSessionStart, computed as hasUserMessageInLoadedSet || hasOlderActions (useConciergeSidePanelReportActions.ts:84-100). When it is false, filterActions returns all actions (no hiding) and hasPreviousMessages short-circuits to false (no button) — exactly the reported symptom.

On the main-DM path both inputs are false at first render:

• The main DM renders cached actions immediately — the loading skeleton is intentionally skipped when isConciergeMainDM && hasCachedReportActions (ReportActionsListContext.tsx:90-101).
• At that first render REPORT_ACTIONS_PAGES pagination metadata is empty, so hasOlderActions (= hasNextPage) is false (PaginationUtils.ts:391-392) — even though the server has prior history.
• The small cached window often contains no prior user message with created < sessionStartTime, so hasUserMessageInLoadedSet is also false.

Result: hadUserMessageAtSessionStart = false → prior history is shown unfiltered and no "Show history" button appears.

The side panel avoids this because it keeps showing the skeleton until hasOnceLoadedReportActions is true, so by the time it renders hasOlderActions is reliable. The main DM does not, which is why the regression is Android/main-DM-specific. The deeper defect is that hasOlderActions is not a reliable "unloaded prior history exists" signal — it is false whenever pagination metadata hasn't loaded yet.

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

On the main-DM path, do not decide hadUserMessageAtSessionStart (and thus reveal all history / hide the button) until report actions have actually finished loading. Concretely: gate that decision on a reliable "loaded" signal — mirror the side panel and wait for hasOnceLoadedReportActions before falling back to "no prior history", or keep the main DM in a loading/skeleton state until the first OpenReport populates REPORT_ACTIONS_PAGES so hasOlderActions is trustworthy. The memos already depend on hasOlderActions, so once it flips to true after load, the correct hidden state will recompute.

What alternative solutions did you explore? (Optional)

Use a more robust "prior history exists" indicator than hasOlderActions for the main-DM case (e.g. derive it from report metadata that is known before pagination pages load), so a self-contained cached page whose lastID === PAGINATION_END_ID doesn't permanently suppress the button.

Confidence & verification

Medium-High. The code path and the exact failing branch are directly evidenced end-to-end; the two independent investigations agreed. Not yet confirmed on-device — an instrumented Android repro capturing hasOlderActions / REPORT_ACTIONS_PAGES length and sessionStartTime at first render vs. after OpenReport would raise this to High. This is client-side render timing, so there are no server logs to check.

Key references:

• Symptom branch — history not hidden: useConciergeSidePanelReportActions.ts:172-180
• Button gate: ShowPreviousMessagesButton.tsx:39-53, wired at ReportActionsList.tsx:385
• isConciergeHiddenHistory (side panel vs main DM): useReportActionsVisibility.ts:69-75
• sessionStartTime source on main DM: ConciergeSessionContext.tsx:76-101

Related issues

• [Due for payment 2026-08-05] [$250] Concierge - After "Concierge is thinking..",current asking via search hidden in Show history #90974 — the original issue that PR fix: keep Concierge side panel question + thinking indicator visible across clock-skew race #94814 fixed (side-panel version of this same behavior). This report is the Android/main-DM counterpart the PR did not cover.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97187) 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 - @thesahindia (External)

[melvin-bot]

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

[dilshodmackbook-sketch]

I authored #94814 (the fix for #90974, the side-panel version of this hidden-history behavior). #97187 is the Android / main-DM counterpart of that same behavior — a path #94814 did not touch. I pulled the attached Applause recording and traced the full session-boundary lifecycle end to end; proposal below.

Proposal

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

On Android, asking Concierge from search opens the main Concierge DM with the entire prior conversation still visible and no "Show history" button. In the attached recording the earlier receipt / SmartScan conversation stays visible above the new "How to connect QBD" question for the whole session — a persistent state, not a brief flash.

What is the root cause of that problem?

Android has no Concierge side panel (isSidePanelReportSupported/index.native.ts is false), so "Ask Concierge" opens the main Concierge DM. Whether history hides is decided against the session boundary sessionStartTime, and the platforms differ in one decisive way:

• Web: every "Ask Concierge" re-anchors the boundary to now — openSidePanel calls setSessionStartTime(getServerAnchoredDBTime()) on each open.
• Native: no code path moves the main-DM boundary forward within a session's 2-hour lifetime. openConciergeAnywhere only navigates — it never touches the session. The only writer is useStartConciergeSession → startSession(oldestUnreadReportAction?.created), and startSession keeps the existing boundary while the session is younger than CONCIERGE_SESSION_EXPIRATION_MS (2 hours) and can only move it earlier, via the cold-open unread pull-back at ConciergeSessionContext.tsx#L88.

In the repro the account interacted with Concierge shortly before the flow (the precondition history), so that session is still active — on native the Concierge screen also stays mounted in the navigation stack (see the comment at useStartConciergeSession.ts#L46-L48). "Ask Concierge" therefore inherits the old boundary: the entire prior conversation sits at/after it, so it counts as in-session and stays visible. And hadUserMessageAtSessionStart = hasUserMessageInLoadedSet || hasOlderActions resolves false — no user message predates the stale boundary and the test account's history fits a single page — so filterActions returns everything unfiltered and hasPreviousMessages short-circuits to false: history shown, no button. The state is persistent, exactly as recorded — nothing in that memo's inputs is "still loading"; the boundary itself is stale, so it never self-corrects.

There is an aggravator that constrains the fix: the unread anchor is derived from a lastReadTime snapshot latched once via useInitial and never refreshed, and findLast returns the oldest action newer than that stale snapshot. The refocus startSession keeps feeding this already-read anchor, so the pull-back would immediately drag even a freshly re-anchored boundary back. Any fix that only creates a new boundary, without exempting it from the pull-back, is undone on the next layout effect.

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

Give native the same contract web already has: an explicit "Ask Concierge" starts a fresh session, and an explicit session is not refined backwards by the cold-open pull-back (that refinement exists only for auto sessions that locked to now before the unread anchor loaded).

1. In ConciergeSessionContext, add an explicit restartSession action and mark such sessions so startSession skips the pull-back for them:

const isExplicitSessionRef = useRef(false);

const restartSession = useCallback(() => {
    isExplicitSessionRef.current = true;
    sessionCreatedAtRef.current = Date.now();
    setSessionStartTime(getServerAnchoredDBTime());
    setShowFullHistory(false);
    setHadMessagesAtSessionStart(false);
}, []);

if (elapsed < CONST.CONCIERGE_SESSION_EXPIRATION_MS) {
    if (!isExplicitSessionRef.current && unreadBoundary && unreadBoundary < prev) {
        return unreadBoundary;
    }
    return prev;
}

(isExplicitSessionRef resets to false whenever a new auto session is created on expiry, and on the existing account-switch reset.)

2. In useOpenConciergeAnywhere/index.native.tsx, call it before navigating — the direct native counterpart of openSidePanel's re-anchor:

const {restartSession} = useConciergeSessionActions();

const openConciergeAnywhere = (_options?: {forceConcierge?: boolean}) => {
    restartSession();
    navigateToConciergeChat(conciergeReportID, introSelected, currentUserAccountID, isSelfTourViewed, betas);
};

With the boundary at now, the prior conversation is pre-session: hadUserMessageAtSessionStart turns true straight from the loaded cache (the prior user messages have created < now), with no dependence on hasOlderActions timing. History hides, the greeting and the new question render, and "Show history" appears — identical to the web side panel.

This is safe for the surrounding flows: cold-open auto sessions are untouched, so the unread pull-back still keeps a notification message visible; plain navigation to Concierge from the LHN doesn't call restartSession, so within-2-hour session continuity behaves as designed; web is unchanged (the call site is the native entry file).

What specific scenarios should we cover in automated tests to prevent reintroducing this bug in the future and to make sure we're not breaking anything when making changes in the future?

Extend tests/unit/hooks/useConciergeSidePanelReportActions.test.ts plus session-context coverage:

• Active main-DM session younger than 2 hours, then "Ask Concierge" (restartSession): boundary re-anchors to now, prior actions are filtered out, hasPreviousMessages is true ("Show history" shows).
• restartSession followed by startSession(staleAnchor) (the refocus re-fire): the boundary is not pulled back.
• Cold open with a genuinely unread action: auto startSession then a late-resolving anchor still pulls the boundary back (guards the notification-visibility behavior).
• Fresh account with no prior history: greeting shown, no button (hadUserMessageAtSessionStart is false).
• Side-panel path (isConciergeMainDM = false) unaffected by the new action.

What alternative solutions did you explore? (Optional)

• Gating the unread anchor against the live report.lastReadTime so an already-read action is never passed to startSession. This hardens the anchor but does not produce the new boundary the flow needs: with the anchor dropped, startSession keeps the existing sub-2-hour boundary (ConciergeSessionContext.tsx#L81-L90), so the prior conversation remains in-session and visible in this repro. Useful as a complement, not a replacement.
• Gating the hidden-history decision on hasOnceLoadedReportActions (skeleton parity with the side panel). This only addresses the pre-load window where hasOlderActions is not yet reliable; here the boundary itself is stale, so the decision stays wrong after load completes. Worth keeping as hardening, not the fix.

Confidence & verification

High. The chain is evidenced end to end at the pinned SHA: web re-anchors per open, native has no forward re-anchor within the 2-hour session lifetime, and the pull-back can only move the boundary earlier — which is the only account consistent with the persistently visible history in the attached recording (a loading-timing cause would self-correct once pagination resolves, since hadUserMessageAtSessionStart is a live memo). As the author of #94814 I have full context on this logic and can implement and verify on-device.

[dilshodmackbook-sketch]

@thesahindia this one traces back to #94814, which I authored — it's the Android / main-DM counterpart of that same Concierge hidden-history behavior. I've left a proposal above with the root cause (confirmed against the attached recording) and the fix approach. Since I already have full context on this logic, could you assign me here?

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

The flow is Android-only because "Ask Concierge" resolves to a different surface per platform. useAskConcierge calls openConciergeAnywhere() and then addComment(...) (useAskConcierge.tsx:29-47). On web useOpenConciergeAnywhere opens the Concierge side panel (isInSidePanel: true); on native it returns isInSidePanel: false and navigateToConciergeChat navigates to the Concierge main DM:

App/src/hooks/useOpenConciergeAnywhere/index.native.tsx

Lines 22 to 26 in bbb00c6

	const openConciergeAnywhere = (_options?: {forceConcierge?: boolean}) => {
	navigateToConciergeChat(conciergeReportID, introSelected, currentUserAccountID, isSelfTourViewed, betas);
	};
	return {openConciergeAnywhere, isInSidePanel: false};

So on Android the hidden-history view is driven by the main-DM session, whose boundary is mainDMSessionStartTime (useReportActionsVisibility.ts:74-75). That value is produced by startSession(oldestUnreadReportAction?.created):

App/src/hooks/useStartConciergeSession.ts

Lines 34 to 55 in bbb00c6

	useLayoutEffect(() => {
	if (!isConciergeMainDM || !canStartConciergeSession) {
	return;
	}
	// Anchor the session to the unread action's created time, a stable pre-read
	// boundary, rather than the live report.lastReadTime which readNewestAction
	// bumps to `now` when the report opens. Re-runs when oldestUnreadReportAction
	// resolves so a session that locked to `now` before the anchor loaded is
	// pulled back to keep the unread message visible.
	startSession(oldestUnreadReportAction?.created);
	}, [isConciergeMainDM, startSession, canStartConciergeSession, oldestUnreadReportAction?.created]);
	// On native the component stays mounted in the navigation stack, so the
	// effect above never re-fires (its isConciergeMainDM dep is always true).
	// Re-trigger startSession when the globally-focused report matches this
	// report so the session age check runs after navigating away and back.
	useLayoutEffect(() => {
	if (!isConciergeMainDM || !canStartConciergeSession || currentReportID !== reportID) {
	return;
	}
	startSession(oldestUnreadReportAction?.created);
	}, [currentReportID, reportID, isConciergeMainDM, canStartConciergeSession, startSession, oldestUnreadReportAction?.created]);

oldestUnreadReportAction is sortedAllReportActions.findLast((a) => a.created > initialLastReadTime), where initialLastReadTime for Concierge is firstDefinedLastReadTime = useInitial(report?.lastReadTime) — a value latched once on first render and never refreshed:

App/src/hooks/usePaginatedReportActions.ts

Lines 56 to 82 in bbb00c6

	// Default (regular inbox chats): snapshot lastReadTime at first render via a ref — production behavior.
	const firstRenderLastReadTime = useRef(report?.lastReadTime);
	// Concierge only: snapshot the first non-undefined lastReadTime. On a cold open the report can be
	// undefined on first render; useInitial waits for the first defined (pre-read) value instead of
	// latching undefined like a first-render ref, so the unread anchor can still resolve after the report loads.
	const firstDefinedLastReadTime = useInitial(report?.lastReadTime);
	const id = useMemo(() => {
	/* eslint-disable react-hooks/refs -- firstRenderLastReadTime snapshots lastReadTime at first render for a stable unread anchor */
	if (treatAsNoPaginationAnchor) {
	return undefined;
	}
	if (reportActionID) {
	return reportActionID;
	}
	if (!shouldLinkToOldestUnreadReportAction) {
	return undefined;
	}
	const initialLastReadTime = shouldSnapshotInitialLastReadTime ? firstDefinedLastReadTime : firstRenderLastReadTime.current;
	if (!initialLastReadTime || !sortedAllReportActions?.length) {
	return undefined;
	}
	return sortedAllReportActions.findLast((reportAction) => reportAction.created > initialLastReadTime)?.reportActionID;

On native the Concierge report screen stays mounted in the navigation stack (see the comment at useStartConciergeSession.ts:46-48), so that snapshot holds a stale, pre-read lastReadTime from an earlier visit. oldestUnreadReportAction therefore points at an old, already-read action, and startSession pulls the boundary back to its created — either through the active-session pull-back or the base branch:

App/src/pages/inbox/ConciergeSessionContext.tsx

Lines 86 to 100 in bbb00c6

	// isn't hidden behind "Show full history". The session age (sessionCreatedAtRef)
	// is unchanged — only the display boundary is refined.
	if (unreadBoundary && unreadBoundary < prev) {
	return unreadBoundary;
	}
	return prev;
	}
	sessionExpired = true;
	}
	sessionCreatedAtRef.current = Date.now();
	const now = getServerAnchoredDBTime();
	if (unreadBoundary && unreadBoundary < now) {
	return unreadBoundary;
	}
	return now;

sessionStartTime now sits earlier than the account's prior user messages. In hadUserMessageAtSessionStart the test action.created < sessionStartTime is then false for every prior user message (they are all >= the pulled-back boundary), and with the history fitting one page hasOlderActions is false, so the memo returns false:

App/src/hooks/useConciergeSidePanelReportActions.ts

Lines 84 to 92 in bbb00c6

	const hadUserMessageAtSessionStart = useMemo(() => {
	if (!isConciergeHiddenHistory || !sessionStartTime) {
	return false;
	}
	const hasUserMessageInLoadedSet = visibleReportActions.some(
	(action) => !isCreatedAction(action) && action.actorAccountID === currentUserAccountID && action.created < sessionStartTime,
	);
	return hasUserMessageInLoadedSet || hasOlderActions;
	}, [isConciergeHiddenHistory, visibleReportActions, currentUserAccountID, sessionStartTime, hasOlderActions]);

With hadUserMessageAtSessionStart === false, filterActions returns the actions unfiltered so prior history is not hidden (useConciergeSidePanelReportActions.ts:178-180), and both showConciergeGreeting and hasPreviousMessages are gated on it (useConciergeSidePanelReportActions.ts:111-112), so ShowPreviousMessagesButton early-returns on !hasPreviousMessages (ShowPreviousMessagesButton.tsx:48-49). That is the exact symptom: history not hidden, no "Show history" button.

Sibling contrast. On web the same query opens the side panel, whose sessionStartTime is set to getServerAnchoredDBTime() (now) by openSidePanel with no pull-back logic (SidePanelContextProvider.tsx:151-154), so prior messages are always < now, hadUserMessageAtSessionStart is true, and history hides with the button — which is why only Android reproduces. The same silence holds on native for a genuinely fresh mount, where useInitial latches the post-addComment lastReadTime (now) and no stale anchor exists; the bug needs the persisted-mount stale snapshot.

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

We should only anchor the main-DM session to the unread action when it is still unread against the live lastReadTime, so an already-read stale anchor can no longer drag sessionStartTime behind the user's own question. In useStartConciergeSession, accept the report's current lastReadTime and gate the boundary before passing it to startSession:

-function useStartConciergeSession({reportID, isConciergeMainDM, oldestUnreadReportAction, hasOnceLoadedReportActions, hasCachedReportActions}: UseStartConciergeSessionParams) {
+function useStartConciergeSession({reportID, isConciergeMainDM, oldestUnreadReportAction, hasOnceLoadedReportActions, hasCachedReportActions, lastReadTime}: UseStartConciergeSessionParams) {
     ...
+    // oldestUnreadReportAction is derived from a frozen first-render lastReadTime snapshot that, on native,
+    // persists across navigations and can point at an already-read action. Only anchor to it while it is still
+    // unread against the live lastReadTime; otherwise it would pull sessionStartTime before the user's own message.
+    const unreadSessionBoundary =
+        oldestUnreadReportAction && (!lastReadTime || oldestUnreadReportAction.created > lastReadTime) ? oldestUnreadReportAction.created : undefined;

Then pass unreadSessionBoundary in place of oldestUnreadReportAction?.created in both startSession(...) calls (and their dependency arrays). Finally, add lastReadTime: report?.lastReadTime to the call site — report is already in scope there (ReportActionsSkeletonGuard.tsx:42-48).

This is safe because:

• addComment optimistically sets report.lastReadTime to the new message time (lastReadTime: currentTime, Report/index.ts:965-974), so after "Ask Concierge" the stale anchor is < lastReadTime and dropped; the session anchors to now and hides prior history with the "Show history" button, matching the web side panel.
• A plain Concierge open with genuinely unread messages is unchanged: opening the report does not advance lastReadTime for Concierge (openReport doesn't set it and readNewestAction is task-gated), so oldestUnreadReportAction.created > lastReadTime still holds and the boundary is still passed — the pull-back keeps the notification message visible as designed (ConciergeSessionContext.tsx:82-90).
• The cold-open fix (#93196) is preserved: while report.lastReadTime is still undefined the !lastReadTime branch keeps passing the boundary exactly as today; the guard only ever drops a boundary once the live lastReadTime proves it read.

Note: the pull-back mechanism itself is untouched — we are not removing it, only refusing to feed it an already-read action as the boundary.

What alternative solutions did you explore? (Optional)

• Give the native "Ask Concierge" entry a fresh now-anchored session (mirroring openSidePanel) from useOpenConciergeAnywhere. This fails because the auto startSession in useStartConciergeSession immediately re-fires with the stale oldestUnreadReportAction, and its pull-back (unreadBoundary < prev) drags the boundary back again — the fresh anchor is undone unless the stale anchor is fixed at the source.
• Enable firstUserMessageCreated for the main DM and hide everything before the user's question. This discards the main-DM unread-boundary behavior: genuinely unread messages that arrived before the question would be forced behind "Show history", regressing the intended notification-visible design.

[thesahindia]

@thesahindia this one traces back to #94814, which I authored — it's the Android / main-DM counterpart of that same Concierge hidden-history behavior. I've left a proposal above with the root cause (confirmed against the attached recording) and the fix approach. Since I already have full context on this logic, could you assign me here?

cc: @thelullabyy