[HOLD][$250] Concierge Shows Duplicate Disambiguation Options (Buttons + Numbered Text) for Ambiguous Expense Edits

[m-natarajan]

On hold for https://github.com/Expensify/Expensify/issues/620494

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: 9.3.65-6
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: Applause Internal Team
Slack conversation (hyperlinked to channel name): #Expensify QA

Action Performed:

1. Open an expense report in a workspace with multiple expenses
2. Send an ambiguous request to Concierge (e.g., “Update the description to meeting with client”)
3. Observe the response options

Expected Result:

Disambiguation options should appear:
Only as clickable follow-up buttons

Actual Result:

Disambiguation options appear as:
Clickable buttons and numbered inline text options

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022050602576199541715
• Upwork Job ID: 2050602576199541715
• Last Price Increase: 2026-05-02

[MelvinBot]

Proposal

What is the root cause of that problem?

The server sends Concierge disambiguation messages with a <followup-list> custom HTML element embedded in the message HTML. The client correctly parses this HTML to generate clickable buttons (in ChatActionableButtons.tsx), but does not strip the <followup-list> from the message body before rendering it.

Since followup-list, followup, followup-text, and followup-response are not registered in BaseHTMLEngineProvider.tsx's customHTMLElementModels, react-native-render-html falls back to rendering their text content as plain inline text. This causes the options to appear twice: once as inline text in the message body, and once as clickable buttons below it.

A stripFollowupListFromHtml function already exists and is used for LHN preview text and clipboard copy, but is not called in the main message rendering path in TextCommentFragment.tsx.

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

In TextCommentFragment.tsx, strip the <followup-list> from the HTML before it's passed to RenderCommentHTML. Import and apply stripFollowupListFromHtml to the html value extracted from the fragment, so the followup tags are removed before rendering while the buttons continue to be generated separately by ChatActionableButtons.

What alternative solutions did you explore? (Optional)

An alternative would be to register the followup tags (followup-list, followup, followup-text, followup-response) in BaseHTMLEngineProvider.tsx's customHTMLElementModels with a hidden/empty rendering model. However, stripping the HTML is simpler, consistent with what's already done for LHN previews and clipboard, and avoids adding unnecessary custom element models.

---

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 - @jjcoffee (External)

[MobileMage]

Proposal

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

When Concierge sends a disambiguation message for an ambiguous expense edit (e.g., updating a description when multiple expenses match), the response shows both clickable option buttons and the same options as a numbered inline list in the message body. Users see duplicate disambiguation UI — the numbered text in the message and the buttons both display the same choices.

What is the root cause of that problem?

The backend delivers CONCIERGE_CATEGORY_OPTIONS and CONCIERGE_DESCRIPTION_OPTIONS report actions with two independent data sources representing the same choices: the action.message text (which contains the full numbered list, e.g. "Which expense did you mean?\n1. Option A\n2. Option B") and the originalMessage.options array. The rendering layer uses both without coordination. In getReportActionMessageFragments in ReportActionsUtils.ts, the branch for these two action types simply returns the raw action.message text, numbered list included:

App/src/libs/ReportActionsUtils.ts

Lines 2453 to 2456 in 1dd01da

	if (isConciergeCategoryOptions(action) || isConciergeDescriptionOptions(action)) {
	const message = getReportActionMessageText(action);
	return [{text: message, html: message, type: 'COMMENT'}];
	}

Then ChatActionableButtons independently reads originalMessage.options and renders a button for each one. Both ReportActionItemMessage (which uses the fragments from getReportActionMessageFragments) and ChatActionableButtons are rendered together in PureReportActionItem, so the user sees the numbered text and the buttons simultaneously.

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

The fix should be applied in getReportActionMessageFragments in src/libs/ReportActionsUtils.ts. For isConciergeCategoryOptions and isConciergeDescriptionOptions actions, instead of returning the full raw message text, the function should return only the introductory prompt — stripping the numbered list portion. The options are already present in originalMessage.options and are rendered as actionable buttons by ChatActionableButtons, so they don't need to appear in the message body at all.

The cleanest approach is to extract the prompt by taking only the text content that precedes the numbered list. Since the originalMessage.options array already holds the individual choices, the fragment returned here can be constructed by removing those numbered entries from the message text. A regex that strips trailing lines matching the pattern \d+\.\s+... (or more simply, stripping everything after a line that starts with 1.) from the message text would isolate the conversational prompt. Alternatively, since the structure is known, the function can use the options array length to trim the last N lines from the message text. The returned fragment should keep its type: 'COMMENT' but contain only the question/prompt portion of the message, leaving the options exclusively to the button rendering path.

App/src/libs/ReportActionsUtils.ts

Lines 2453 to 2456 in 1dd01da

	if (isConciergeCategoryOptions(action) || isConciergeDescriptionOptions(action)) {
	const message = getReportActionMessageText(action);
	return [{text: message, html: message, type: 'COMMENT'}];
	}

What alternative solutions did you explore? (Optional)

N/A

[melvin-bot]

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

[samranahm]

It's internal.

[Hossiy21]

Proposal:

I cloned the Expensify repo yesterday while working on another issue and have already reviewed this bug in the codebase.
The root cause is in src/libs/ReportActionsUtils.ts in the getReportActionMessageFragments function. For isConciergeCategoryOptions and isConciergeDescriptionOptions actions, the full raw message including the numbered list is returned as a fragment, while ChatActionableButtons independently renders the same options as buttons — causing the options to appear twice.
The fix is to strip the numbered list portion from the message text before returning the fragment, since the options are already rendered as actionable buttons. A stripFollowupListFromHtml function already exists in the codebase and is used for LHN previews and clipboard — I will apply the same consistent approach in the message rendering path in TextCommentFragment.tsx.
This is a minimal, surgical change scoped to one or two files with no regression risk to other action types.

[15antonian]

Proposal

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

When Concierge sends a disambiguation message for an ambiguous expense edit (such as editing a description when multiple matching expenses exist), the same options appear twice: as a numbered list in the message body and as clickable numbered buttons below it. The user sees duplicate disambiguation UI for the same choices.

What is the root cause of that problem?

The CONCIERGE_CATEGORY_OPTIONS and CONCIERGE_DESCRIPTION_OPTIONS action types carry the available choices in two independent places: the raw action.message text (which contains the full prompt plus a numbered list like "1. Expense A\n2. Expense B") and the originalMessage.options array. The rendering layer uses both without coordination.

In getReportActionMessageFragments in ReportActionsUtils.ts:2453, the branch for these two action types calls getReportActionMessageText(action) and returns the entire message — numbered options included — as both text and html for the comment fragment:

// Before fix — full message with numbered options returned
if (isConciergeCategoryOptions(action) || isConciergeDescriptionOptions(action)) {
    const message = getReportActionMessageText(action);
    return [{text: message, html: message, type: 'COMMENT'}];
}

Separately, ChatActionableButtons.tsx:75-130 reads getOriginalMessage(action)?.options and renders a button for each entry (formatted as ${i + 1} - ${option}). Both the fragment message and the buttons are rendered together in PureReportActionItem, so the numbered options appear twice.

The options array from ChatActionableButtons.tsx:76 is the authoritative source for the choices. The message body only needs to show the conversational question prompt — not the list.

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

In getReportActionMessageFragments in ReportActionsUtils.ts, after getting the message text, use options.length (from getOriginalMessage(action)?.options) to trim exactly the trailing N lines from the message. This leaves only the question prompt and preserves the options exclusively in the button rendering path.

Using options.length to determine how many lines to strip is more precise than a regex because the number of trailing option lines matches the number of options entries exactly — no guessing at line format is needed. The same getOriginalMessage import is already used in ChatActionableButtons and is already in scope in ReportActionsUtils.ts.

Compare branch: https://github.com/Expensify/App/compare/main...15antonian:App:fix/89428-concierge-options-duplicate-text?expand=1

What alternative solutions did you explore? (Optional)

Option: apply stripFollowupListFromHtml in TextCommentFragment.tsx (MelvinBot's approach). Rejected because CONCIERGE_CATEGORY_OPTIONS and CONCIERGE_DESCRIPTION_OPTIONS messages do not use <followup-list> HTML tags — getReportActionMessageFragments for these action types calls getReportActionMessageText which returns plain text, not HTML with followup-list elements. That fix addresses a separate category of messages (Concierge followup prompts, not disambiguation options).

Option: strip numbered lines with a regex matching \d+\.\s+.... Rejected because a regex must assume the text format of each option line, which could match false positives in expense descriptions that begin with a number followed by a period. Using options.length directly avoids any format assumption.

Option: register followup-list and related tags in BaseHTMLEngineProvider.tsx with hidden rendering. Rejected because it applies only to the followup-list HTML path, not to the plain-text CONCIERGE_CATEGORY_OPTIONS path, and adds unnecessary custom element models for a tag that should simply not appear in the rendered message at all.