[$250] Concierge - Show history button is not displayed

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.66-4
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: #88392
Email or phone of affected tester (no customers): applausetester@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.3
App Component: Other

Action Performed:

1. Open the Expensify app
2. Log in with an account with prior Concierge conversations
3. Open the Concierge side panel

Expected Result:

The "Show history" button is displayed.

Actual Result:

The "Show history" button is not displayed.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @cretadn22

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022051517183806137299
• Upwork Job ID: 2051517183806137299
• Last Price Increase: 2026-05-26

[MelvinBot]

Proposal

What is the root cause of that problem?

The "Show history" button is a side-panel-only feature. It only renders when isInSidePanel === true (via IsInSidePanelContext), which is only set to true inside SidePanelReport.

On native mobile, the Concierge help button (SidePanelButton/index.native.tsx) calls navigateToConciergeChat(), which opens the Concierge chat as a regular report screen — NOT inside the side panel. This means isInSidePanel is always false on native, so the ShowPreviousMessagesButton early-returns null.

This is not a regression from PR #88392 (which only extracted the button into a separate component without changing its logic). The native Concierge help button was added in PR #87395 (merged April 30) using direct navigation instead of the side panel, so the "Show history" feature was never available on native.

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

Modify the native SidePanelButton/index.native.tsx to call openSidePanel() (like the web version does) instead of navigateToConciergeChat(). The side panel modal infrastructure already exists on native — both SidePanelModal/index.android.tsx and SidePanelModal/index.ios.tsx render right-docked modals. This would make the native experience consistent with web: the Concierge chat opens in the side panel with history filtering and the "Show history" button.

Similarly, update useOpenConciergeAnywhere/index.native.tsx to use openSidePanel() and return isInSidePanel: true.

What alternative solutions did you explore? (Optional)

An alternative would be to make ShowPreviousMessagesButton and useConciergeSidePanelReportActions work outside the side panel context (i.e., in the regular Concierge chat view). However, this was explicitly ruled out in the original design (PR #81807, Test 4: "Open the Concierge chat in the main view — Expected: Full chat history is displayed normally with no 'Show history' button"). Reusing the side panel modal on native is the cleaner approach since all the infrastructure already exists.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

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

[melvin-bot]

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

[neerajbachani]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-05 06:14:21 UTC.

Proposal

What is the root cause of that problem?

Two root causes:

1. In useConciergeSidePanelReportActions, hasPreviousMessages only checked for pre-session messages already loaded in memory. For long Concierge histories, older messages can exist but still be paginated out (hasOlderActions === true), so the "Show previous messages" button stayed hidden even when history existed.

2. On native, Concierge entry paths were not opening through the side-panel flow. ShowPreviousMessagesButton is side-panel-only (gated by useIsInSidePanel()), so when Concierge opened as a fullscreen chat, it returned null even if history existed.

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

1. Fix hasPreviousMessages logic in the hook:

// Before
return visibleReportActions.some((action) => !isCreatedAction(action) && action.created < sessionStartTime);

// After
const hasLoadedPreSessionMessage = visibleReportActions.some((action) => !isCreatedAction(action) && action.created < sessionStartTime);
return hasLoadedPreSessionMessage || hasOlderActions;

2. Align native Concierge entry with web side-panel behavior:

• SidePanelButton/index.native.tsx — delegate to SidePanelButtonBase (same as web) instead of calling navigateToConciergeChat directly.
• useOpenConciergeAnywhere/index.native.tsx — open side panel and return isInSidePanel: true:

// Before
return {openConciergeAnywhere, isInSidePanel: false};

// After
return {openConciergeAnywhere, isInSidePanel: true};

3. Mount the side-panel host on native:

• RootNavigatorExtraContent/index.native.tsx — render <SidePanel /> so SidePanelReport provides the side-panel context required by ShowPreviousMessagesButton. Additionally, normalize native side-panel top inset to remove extra top gap without changing web behavior

4. Add regression tests:

• Hook test: hasPreviousMessages is true when hasOlderActions is true even if no pre-session actions are loaded yet.
• Hook test: hasPreviousMessages is false when both hasOlderActions is false and no pre-session action is loaded.

What alternative solutions did you explore? (Optional)

1. Remove side-panel gating from ShowPreviousMessagesButton so it renders in fullscreen native chat too.
   Rejected — changes product behavior and breaks the side-panel session isolation logic.

2. Treat this as an HTML custom-tag rendering issue (transaction-history-link).
   Rejected — the bug is on the ShowPreviousMessagesButton path, not the HTML renderer path.

Video Demo

lv_0_20260505135215.mp4

Test Branch
https://github.com/neerajbachani/App/tree/test/concierge-sidepanel-verify

[github-actions]

⚠️ @neerajbachani Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[Ltbltbltbltb]

Proposal

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

Users with Concierge history open the Concierge side panel on native mobile, but the expected “Show history” CTA is not rendered.

What is the root cause of that problem?

The custom history CTA is rendered through the HTML engine, but transaction-history-link is registered as HTMLContentModel.textual in BaseHTMLEngineProvider. On native, that forces the custom renderer into an inline text rendering path, while TransactionHistoryLinkRenderer is actually an interactive CTA. The renderer is correctly registered in HTMLRenderers/index.ts, but the tag model prevents it from behaving like a standalone interactive element in this native message surface.

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

Change only the custom element model for transaction-history-link so the HTML engine treats it as mixed/block-capable content instead of plain textual content. That keeps the existing renderer and navigation behavior, but lets the native Concierge side panel render the CTA consistently.

// src/components/HTMLEngineProvider/BaseHTMLEngineProvider.tsxx
'transaction-history-link': HTMLElementModel.fromCustomModel({
    tagName: 'transaction-history-link',
    contentModel: HTMLContentModel.mixed,
}),

No report action loading logic needs to change. This fixes every path that renders the “Show history” CTA through the HTML engine because all of them go through the same custom tag registration before reaching TransactionHistoryLinkRenderer.

Contributor Details

Field	Value
Contributor email	lucastrba@gmail.com
Upwork Profile	https://www.upwork.com/freelancers/~01d016059c6701ebaa

[twilight2294]

Proposal

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

When a user with prior Concierge history opens the Concierge side panel, the "Show history" button doesn't appear even though older messages exist.

What is the root cause of that problem?

The bug is in hasPreviousMessages inside useConciergeSidePanelReportActions. It checks only visibleReportActions (the currently loaded page) for pre-session messages — but for users with long history, those older messages aren't loaded yet. hasOlderActions is true, but the computation ignores it, so hasPreviousMessages stays false and the button never renders.

One block above it, hadUserMessageAtSessionStart already handles this correctly with return hasUserMessageInLoadedSet || hasOlderActions. The hasPreviousMessages computation is missing the same fallback.

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

Add || hasOlderActions to hasPreviousMessages in useConciergeSidePanelReportActions, mirroring the pattern hadUserMessageAtSessionStart already uses:

 const hasPreviousMessages = useMemo(() => {
     if (!isConciergeSidePanel || !hadUserMessageAtSessionStart || !sessionStartTime) {
         return false;
     }
-    return visibleReportActions.some((action) => !isCreatedAction(action) && action.created < sessionStartTime);
-}, [isConciergeSidePanel, visibleReportActions, sessionStartTime, hadUserMessageAtSessionStart]);
+    return hasOlderActions || visibleReportActions.some((action) => !isCreatedAction(action) && action.created < sessionStartTime);
+}, [isConciergeSidePanel, visibleReportActions, sessionStartTime, hadUserMessageAtSessionStart, hasOlderActions]);

hasOlderActions is already a parameter of the hook (line 14), so no new props are needed. The fix is one line.

What alternative solutions did you explore? (Optional)

neerajbachani's proposal identifies the same root cause but doesn't specify the exact fix or note the dependency array change (hasOlderActions must be added). It also doesn't call out that hadUserMessageAtSessionStart already implements the correct pattern — the fix is literally adding the same || hasOlderActions escape hatch that exists one block above.

MelvinBot's proposal targets a different root cause entirely (native navigation not using the side panel). That's a separate issue; on web the side panel is used correctly and the button still doesn't appear, which this fix addresses.