[$250] Split - Missing "Who was there?" header when split expense in Group DM

[applause-bot]

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.4.32-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-54985/folder/13177029/41237802/1554722014?sort=%2Bidentifier
Email or phone of affected tester (no customers): leungbratt6+09074@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 10/Chrome
App Component: Money Requests

Action Performed:

1. Open the NewDot app
2. Navigate to a Group ,click the + icon in a Group conversation
3. Click/tap on the "Split expense" option
4. Enter an amount into the BNP and select the Next confirmation button

Expected Result:

6. Verify that all the participants of the Group DM are populated under the Who was there? header.

Actual Result:

There is no "Who was there?" header

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022075226759932399860
• Upwork Job ID: 2075226759932399860
• Last Price Increase: 2026-07-16

[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/0101bb79869859e80c55cd751348168b25a63d2e05a7a5e718dde91446f1e5a5

[MelvinBot]

Issue Analysis

Root Cause (medium confidence): The split-confirmation participant list now renders through the new SelectionListWithSections, whose useFlattenedSections only emits a section's header when that section has at least one row. So when the split "participants" section renders empty, the header (what the tester calls "Who was there?" — it's now iou.participants = "Participants") is silently dropped instead of showing.

The gate:

• useFlattenedSections.ts:57 — const hasHeader = sectionDataLength > 0 && (section.customHeader ?? section.title); A customHeader is only pushed when the section has rows.
• The split participants section is built at useConfirmationSections.ts:77-81 with customHeader: getSplitSectionHeader() and data: splitParticipants.
• splitParticipants is derived from selectedParticipants — which is selectedParticipantsProp.filter((p) => p.selected) — in useSplitParticipants.tsx:84-150.

When the Group DM members don't reach the confirmation with selected: true (or iouType isn't SPLIT at render), that section collapses to zero rows and the header — plus the participant list — disappears. Before the section-list migration the header rendered regardless, which is why this reads as a regression.

Recommended Fix: Ensure the Group DM's members are populated on the draft transaction with selected: true before the confirmation renders so the participants section is non-empty. getMoneyRequestParticipantsFromReport already maps group members with selected: true, so the gap is most likely in how/when those participants are propagated to the confirmation for the Group DM split path — that's the spot to trace and fix. (Simply un-gating the header in useFlattenedSections would surface an empty header with no participants, so it treats the symptom, not the cause.)

Investigation details & open question

Why "no header at all" (not just an empty list): For a split, two sections are pushed — a "Paid by" section and the participants section. The participants header only vanishes when its section has zero rows. Because splitParticipants = [payeeOption, ...selectedParticipants] normally includes the payee, an entirely missing header points to the split section not being built with the group members (empty selectedParticipants) and/or the split branch not being taken — i.e. the participants aren't arriving on the draft transaction with selected: true for the Group DM flow.

Open question (why I'm at medium, not high): I confirmed the rendering mechanism that suppresses the header, but not the exact reason the section is empty for a Group DM specifically. This should be confirmed at runtime by reproducing a Group DM split and inspecting transaction.participants (and iouType) at the confirmation step. This is a client-render issue, so there are no server logs to consult.

Scope note: Repro is on native (Android/iOS app) and Windows Chrome (desktop web), not mWeb — consistent with a shared confirmation-list rendering path rather than a platform-specific one. HEAD is exactly the reported version (v9.4.32-0), so the code above is the buggy code.

---

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

[MobileMage]

Proposal

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

When a user starts a split from a Group DM (+ → Split expense → enter an amount → Next), the confirmation page no longer shows the participants section header (the "Who was there?" / "Participants" list that should enumerate the Group DM members). The section header is missing, so the split participant breakdown reads as absent even though this is a split flow.

What is the root cause of that problem?

The participants list on the split confirmation is the split section built in useConfirmationSections. For isTypeSplit it pushes a "Paid by" section plus a participants section whose header is supplied through customHeader (from getSplitSectionHeader, which renders translate('iou.participants')):

App/src/components/MoneyRequestConfirmationList/hooks/useConfirmationSections.ts

Lines 66 to 78 in 984116c

	if (isTypeSplit) {
	options.push(
	{
	title: translate('moneyRequestConfirmationList.paidBy'),
	data: [getIOUConfirmationOptionsFromPayeePersonalDetail(payeePersonalDetails)],
	sectionIndex: 0,
	},
	{
	customHeader: getSplitSectionHeader(),
	data: splitParticipants,
	sectionIndex: 1,
	},
	);

That header is a customHeader ReactElement rather than a plain title string. The regression lives one layer down, in the SelectionList flattener that turns sections into list rows. A section header is only emitted when the section already has at least one data row:

App/src/components/SelectionList/hooks/useFlattenedSections.ts

Lines 52 to 55 in 984116c

	for (const section of sections) {
	const sectionDataLength = section.data?.length ?? 0;
	itemsTotalCount += sectionDataLength;
	const hasHeader = sectionDataLength > 0 && (section.customHeader ?? section.title);

const sectionDataLength = section.data?.length ?? 0;
const hasHeader = sectionDataLength > 0 && (section.customHeader ?? section.title);

So the customHeader is dropped the moment the participants section resolves to zero rows. In a Group DM the participants are auto-assigned asynchronously by IOURequestStepConfirmation (the effect that calls setMoneyRequestParticipants from the source report), and the confirmation list filters selectedParticipantsProp down to entries with .selected before it reaches useSplitParticipants. On the render where the Group DM members haven't been merged in with selected: true yet, splitParticipants collapses to an empty (or payee-only) list, sectionDataLength is 0, and the sectionDataLength > 0 guard swallows the header. Because this is a customHeader — an explicit, intentional header the caller passed — gating it on row count is wrong: the pre-refactor SelectionList rendered a provided section header independent of the row data, which is why this only regressed after the SelectionList rewrite.

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

Stop gating an explicitly-provided customHeader on the section having rows. A customHeader is passed deliberately by the caller and should render regardless of sectionDataLength; only the auto-generated title header needs the "has rows" guard (to avoid stray empty-section titles elsewhere). In useFlattenedSections, split the condition so the custom header survives an empty section:

const sectionDataLength = section.data?.length ?? 0;
const hasHeader = !!section.customHeader || (sectionDataLength > 0 && !!section.title);

This restores the split "Participants" header for the Group DM flow (and any other consumer that supplies a customHeader), while leaving title-only sections unchanged so no empty-section titles appear anywhere else. It is a one-line, low-risk change scoped to the flattener that produced the regression, and it does not touch the split participant-population logic in useSplitParticipants/useConfirmationSections, so other split entry points (1:1 DM, workspace expense chat) keep their current behavior.

What alternative solutions did you explore? (Optional)

I considered fixing this purely in the participant-assignment path — guaranteeing the Group DM members are merged with selected: true before the confirmation renders so the section is never empty. That masks the symptom for this one flow but leaves the underlying flattener bug in place (any customHeader on a transiently-empty section would still vanish), so fixing the header gate at its source is the more correct and general fix.

[aswin-s]

Proposal

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

When a user initiates a Split expense from a Group DM (+ icon → Split expense → enter amount → Next) on Android, iOS, and Web (v9.4.32-0), the confirmation screen renders the split-participants list without the expected "Who was there?" section header. Expected: participants of the Group DM are populated under a "Who was there?" header on the confirmation screen.

What is the root cause of that problem?

The split-section header in src/components/MoneyRequestConfirmationList/hooks/useSplitParticipants.tsx:156 hardcodes the label as translate('iou.participants'), which resolves to "Participants" per src/languages/en.ts:1326 (iou.participants: 'Participants'). There is no whoWasThere (or equivalent) key in en.ts — grep across the repo returns zero matches — so the "Who was there?" header string no longer exists in the codebase. The header is emitted by getSplitSectionHeader (consumed as customHeader in src/components/MoneyRequestConfirmationList/hooks/useConfirmationSections.ts:78), so every split confirmation — including the Group DM flow described in the repro — renders "Participants" instead of "Who was there?". The regression traces to the confirmation-list refactor in PR #88720, which moved the split-section header rendering into this new hook and dropped the original copy in the process.

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

1. src/languages/en.ts around line 1326 (inside the iou block): add a new key whoWasThere: 'Who was there?' (verbatim per the issue's Expected Result).
2. Mirror the new key in every other locale file under src/languages/ (e.g. es.ts) so the string is translatable.
3. src/components/MoneyRequestConfirmationList/hooks/useSplitParticipants.tsx:156 — change translate('iou.participants') to translate('iou.whoWasThere') inside getSplitSectionHeader so the split confirmation shows the expected header for all IOU types that render this hook (Group DM split is the reported flow, but the same header applies to all splits — the previous copy was "Who was there?" for every split).
4. No other callers need updating: getSplitSectionHeader is only consumed by useConfirmationSections.ts:78 as customHeader for the split section, and platform-agnostic (no .native/.web twins of the hook).
5. Manually verify the repro (Group DM → + → Split expense → amount → Next) on Android, iOS, and Web-Chrome shows the "Who was there?" header above the participants rows.

What alternative solutions did you explore? (Optional)

[samranahm]

Proposal

What is the root cause of that problem?

When a split expense is started from a Group DM and the user taps Next, the confirmation step should render the "Who was there?" section listing every Group DM participant. Instead the section header is absent, so the user cannot see or edit who the split is being divided between.

The confirmation UI is built in MoneyRequestConfirmationList.tsx, which composes the split participants section that carries the "Who was there?" header. That header is only rendered when the participants section is produced with at least one entry. For a Group DM the underlying report is a group chat report, and the split participants are meant to be derived from the report's participants/participantAccountIDs. When the split is initiated from the Group DM, the confirmation list receives the transaction with an empty (or unresolved) selectedParticipants/Split array, so the section is skipped entirely and the header never mounts.

The Split model itself shows each participant is keyed by email/account, so an empty split array means no rows and no header:

App/src/types/onyx/IOU.ts

Lines 90 to 93 in 8fa661f

	/** Model of IOU split */
	type Split = {
	/** IOU split participant email */
	email?: string;

So the gap is: the Group DM's members are never seeded into the split participant list before the confirmation list evaluates whether to show the "Who was there?" section, which is different from a regular workspace/DM split where participants are pre-populated.

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

1. In MoneyRequestConfirmationList.tsx, where the split participants section is assembled, ensure that when the chat report is a Group DM the section is seeded from the report's participant account IDs before deciding whether to render the "Who was there?" header. This guarantees the header and rows appear the same way they do for other split flows.

2. In the split initiation path that maps the source report to selectedParticipants (the IOU participants builder used before navigating to the confirmation step), include all Group DM members so the split array is non-empty by the time MoneyRequestConfirmationList mounts. This is the layer that populates the Split entries shown above, so filling it fixes the empty-section root cause at the source rather than patching only the view.

3. Verify the header rendering condition in the confirmation footer does not hide the section when participants come from a group chat report, so a populated list always shows the "Who was there?" title.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[melvin-bot]

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

[alazarlemma02]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.