[$250] Reports page - Custom report title briefly shows "Chat Report" when clicking a report row

[MelvinBot]

Version Number: N/A
Reproducible in staging?: Unknown
Reproducible in production?: Yes
Email or phone of affected tester (no customers): N/A
Issue reported by: Internal
Slack thread: https://expensify.slack.com/archives/C05LX9D6E07/p1776378578696719

Action Performed:

1. Open New Expensify (Web)
2. Go to the Reports page
3. Set up a report with a custom report title (via title formula)
4. Click on a report row to open the report

Expected Result:

The report title in the title column should remain as the custom report title throughout the transition.

Actual Result:

When clicking on a report row, the custom report title is briefly changed to "Chat Report" before reverting back to the correct custom title once the report loads. This appears to be related to an optimistic update that temporarily replaces the resolved report name with a default/fallback value.

Workaround:

None known — this is a visual flicker only and does not affect functionality.

Platforms:

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

Notes

A similar but distinct issue existed for the chat search/switcher context (#84140), which was closed as not reproducible. This issue is specific to the Reports page and likely involves the custom report title formula not being applied during the optimistic update when a report row is clicked.

Issue Owner

Current Issue Owner: @abbasifaizan70

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022044913230401817001
• Upwork Job ID: 2044913230401817001
• Last Price Increase: 2026-04-30

[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/~022044913230401817001

[MelvinBot]

Proposal

What is the root cause of that problem?

When a report row is clicked, openReport creates an optimistic report update. If reportActionsExist(reportID) returns false (report actions aren't cached yet — common when navigating from the Reports/Search page), it sets reportName to the cached value OR falls back to CONST.REPORT.DEFAULT_REPORT_NAME ('Chat Report').

This optimistic merge overwrites the report's reportName in Onyx. For expense reports with a custom title formula, computeReportName returns report.reportName directly — so if the optimistic merge set it to 'Chat Report', the UI briefly shows that until the server response restores the correct title.

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

The optimistic update in openReport should not overwrite reportName when the report already exists in Onyx with a valid reportName. At src/libs/actions/Report/index.ts:1275-1279, the logic should skip setting reportName in the optimistic data when the report is already cached with a non-empty reportName:

const existingReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`];
const optimisticReport = reportActionsExist(reportID)
    ? {}
    : {
          ...(existingReport?.reportName ? {} : {reportName: CONST.REPORT.DEFAULT_REPORT_NAME}),
      };

This preserves the existing custom report title during the optimistic phase and only falls back to 'Chat Report' when no report name exists at all.

What alternative solutions did you explore? (Optional)

An alternative would be to suppress the optimistic reportName merge entirely when the report already exists in Onyx (i.e., only set reportName for truly new/unknown reports). However, the approach above is more targeted — it preserves the existing behavior for reports without a cached name while fixing the flicker for reports that already have one.

Investigation details

Data flow causing the flicker:

1. User clicks a report row → navigates to SearchMoneyRequestReportPage (or ReportFetchHandler)
2. openReport({reportID}) is called
3. reportActionsExist(reportID) returns false (actions not cached from Search page)
4. Optimistic report merges reportName = cached name ?? 'Chat Report' into Onyx
5. computeReportName at ReportNameUtils.ts:896 returns report.reportName for expense reports → shows 'Chat Report'
6. Server response arrives → overwrites with correct custom title → flicker complete

Key files:

• src/libs/actions/Report/index.ts:1275-1313 — optimistic update logic
• src/libs/ReportNameUtils.ts:896-898 — expense report name resolution
• src/CONST/index.ts:1731 — DEFAULT_REPORT_NAME: 'Chat Report'

---

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.

[abbasifaizan70]

Proposal

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

On New Expensify (Web), opening a report from the Reports page causes the report title to briefly flicker from the resolved custom report title (set via title formula) to the literal string "Chat Report", and then revert back to the correct custom title once the report finishes loading. The expected behavior is that the custom report title remains stable and visible throughout the navigation transition, with no momentary fallback to a default name.

What is the root cause of that problem?

The Reports page renders each row using the derived reportAttributes.reportName Onyx value. reportAttributes is computed by the OnyxDerived config below, which calls computeReportName for every report in the collection — that is the function that resolves the workspace title formula into a human-readable name like TripUSA-2024-12.

App/src/libs/actions/OnyxDerived/configs/reportAttributes.ts

Lines 304 to 326 in f855ba5

	acc[report.reportID] = {
	reportName: report
	? computeReportName({
	report,
	reports,
	policies,
	transactions,
	allReportNameValuePairs: reportNameValuePairs,
	personalDetailsList: personalDetails,
	reportActions,
	currentUserAccountID: session?.accountID ?? CONST.DEFAULT_NUMBER_ID,
	currentUserLogin: session?.email ?? '',
	allPolicyTags: policyTags,
	})
	: '',
	isEmpty: generateIsEmptyReport(report, isReportArchived),
	brickRoadStatus,
	requiresAttention,
	actionBadge,
	actionTargetReportActionID,
	reportErrors,
	oneTransactionThreadReportID,
	};

For an expense report (the type used on the Reports page), computeReportName short-circuits and returns the raw report.reportName field directly — it does not re-derive the title from the formula on every call. So whatever value is sitting in report.reportName in Onyx becomes the displayed title.

App/src/libs/ReportNameUtils.ts

Lines 859 to 898 in f855ba5

	function computeReportName({
	report,
	reports,
	policies,
	transactions,
	allReportNameValuePairs,
	personalDetailsList,
	reportActions,
	currentUserAccountID,
	currentUserLogin,
	allPolicyTags,
	conciergeReportID,
	}: ComputeReportName): string {
	if (!report || !report.reportID) {
	return '';
	}
	const reportPolicy = policies?.[`${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`];
	const parentReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${report?.parentReportID}`];
	const parentReportAction = isThread(report) ? reportActions?.[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${report?.parentReportID}`]?.[report.parentReportActionID] : undefined;
	const parentReportActionBasedName = computeReportNameBasedOnReportAction(
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	translateLocal,
	formatPhoneNumberPhoneUtils,
	parentReportAction,
	report,
	reportPolicy,
	parentReport,
	personalDetailsList,
	conciergeReportID,
	);
	if (parentReportActionBasedName) {
	return parentReportActionBasedName;
	}
	if (report?.reportName && report.type === CONST.REPORT.TYPE.EXPENSE) {
	return report?.reportName;
	}

When the user clicks a row, Report.openReport is dispatched. It builds an optimistic Onyx update for the report. If the report's actions have not been hydrated yet (which is the common case when arriving from a Search snapshot — the REPORT_ACTIONS_<id> key is still empty), it builds an optimisticReport payload that unconditionally includes a reportName field, falling back to CONST.REPORT.DEFAULT_REPORT_NAME (literally the string "Chat Report") whenever the value read from allReports is missing. The optimistic merge then writes that value into ONYXKEYS.COLLECTION.REPORT_<id>.reportName.

App/src/libs/actions/Report/index.ts

Lines 1275 to 1314 in f855ba5

	const optimisticReport = reportActionsExist(reportID)
	? {}
	: {
	reportName: allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]?.reportName ?? CONST.REPORT.DEFAULT_REPORT_NAME,
	};
	const optimisticData: Array<
	OnyxUpdate<
	| typeof ONYXKEYS.COLLECTION.REPORT_METADATA
	| typeof ONYXKEYS.COLLECTION.REPORT
	| typeof ONYXKEYS.COLLECTION.TRANSACTION
	| typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS
	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
	| typeof ONYXKEYS.NVP_INTRO_SELECTED
	| typeof ONYXKEYS.COLLECTION.POLICY
	| typeof ONYXKEYS.NVP_ONBOARDING
	| typeof ONYXKEYS.PERSONAL_DETAILS_LIST
	>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`,
	value: {
	isLoadingInitialReportActions: true,
	isLoadingOlderReportActions: false,
	hasLoadingOlderReportActionsError: false,
	isLoadingNewerReportActions: false,
	hasLoadingNewerReportActionsError: false,
	},
	},
	];
	// Only add the report update if optimisticReport has data
	if (Object.keys(optimisticReport).length > 0) {
	optimisticData.unshift({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: optimisticReport,
	});
	}

The DEFAULT_REPORT_NAME constant that this fallback resolves to:

App/src/CONST/index.ts

Lines 1729 to 1733 in f855ba5

	OWNER_EMAIL_FAKE: '__FAKE__',
	OWNER_ACCOUNT_ID_FAKE: 0,
	DEFAULT_REPORT_NAME: 'Chat Report',
	// Not translated because default report names are not translated on the backend (matches Expensify Classic behavior)
	DEFAULT_EXPENSE_REPORT_NAME: 'New Report',

Putting it together: when the user opens a report from the Reports page, search rows are typically backed by a SNAPSHOT_* Onyx key, so the global ONYXKEYS.COLLECTION.REPORT_<id> entry is either absent or has an empty/stale reportName. The ?? CONST.REPORT.DEFAULT_REPORT_NAME fallback therefore kicks in and the optimistic merge writes reportName: "Chat Report" to the report. Because reportAttributes is derived from the report collection, it immediately recomputes; computeReportName returns report.reportName (now "Chat Report") for the expense report, and the header re-renders with that value. A few hundred milliseconds later, the OpenReport API response arrives, replaces report.reportName with the server-resolved custom title, and the header reverts. The end-user sees a visible flicker from the custom title → "Chat Report" → custom title.

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

The optimistic update should never downgrade an already-known report name to the fallback "Chat Report" string. The fallback only exists to seed a placeholder when the report is being newly created (the isCreatingNewReport branch a few lines below already handles that case explicitly with Onyx.METHOD.SET). For the plain "open an existing report" path, the optimistic merge should either:

• write the existing resolved name (a no-op merge), or
• omit reportName entirely so the merge does not touch the field.

This way, if Onyx already has a real reportName for the report, it is preserved verbatim; if it does not, no "Chat Report" placeholder is injected and the header simply waits one render cycle for the API response — which is far less jarring than flashing the wrong title.

App/src/libs/actions/Report/index.ts

Lines 1275 to 1314 in f855ba5

	const optimisticReport = reportActionsExist(reportID)
	? {}
	: {
	reportName: allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]?.reportName ?? CONST.REPORT.DEFAULT_REPORT_NAME,
	};
	const optimisticData: Array<
	OnyxUpdate<
	| typeof ONYXKEYS.COLLECTION.REPORT_METADATA
	| typeof ONYXKEYS.COLLECTION.REPORT
	| typeof ONYXKEYS.COLLECTION.TRANSACTION
	| typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS
	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
	| typeof ONYXKEYS.NVP_INTRO_SELECTED
	| typeof ONYXKEYS.COLLECTION.POLICY
	| typeof ONYXKEYS.NVP_ONBOARDING
	| typeof ONYXKEYS.PERSONAL_DETAILS_LIST
	>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`,
	value: {
	isLoadingInitialReportActions: true,
	isLoadingOlderReportActions: false,
	hasLoadingOlderReportActionsError: false,
	isLoadingNewerReportActions: false,
	hasLoadingNewerReportActionsError: false,
	},
	},
	];
	// Only add the report update if optimisticReport has data
	if (Object.keys(optimisticReport).length > 0) {
	optimisticData.unshift({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: optimisticReport,
	});
	}

const existingReportName = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`]?.reportName;

const optimisticReport: Partial<Pick<Report, 'reportName'>> = reportActionsExist(reportID) || !existingReportName ? {} : {reportName: existingReportName};

Behavior changes after this fix:

• Opening a report whose reportName is already in Onyx (the normal case from the Reports page / Search row): the optimistic merge re-writes the same value, so reportAttributes does not flip and the header keeps showing the custom title throughout the transition.
• Opening a report whose reportName is not yet in Onyx (e.g. arriving from a deep link before any snapshot has loaded the report): nothing is written to report.reportName at all; the header shows whatever fallback computeReportName already produces (typically an empty string or a chat-thread-derived name), and the real title appears as soon as the OpenReport response lands. No "Chat Report" placeholder is ever shown.
• Creating a brand-new report (isCreatingNewReport === true): unaffected — that branch a few lines below explicitly calls Onyx.METHOD.SET with reportName: CONST.REPORT.DEFAULT_REPORT_NAME plus newReportObject, which is the legitimate use of the placeholder for not-yet-persisted reports.