[$250] [DEV] Expense report/thread not loading properly

[izarutskaya]

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.41-4 (DEV only)
Reproducible in staging?: Needs Reproduction
Reproducible in production?: Needs Reproduction
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: @bernhardoj
Slack conversation (hyperlinked to channel name): #expensify_bugs

Action Performed:

1. Open the App on DEV
2. Go to any expense report or thread

Expected Result:

The report or thread is loaded correctly, showing the report/thread name

Actual Result:

Infinite loading, loaded but with incorrect name or missing parent navigation subtitle (From "..,")

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

web.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080713578935826605
• Upwork Job ID: 2080713578935826605
• Last Price Increase: 2026-08-07

Issue Owner

Current Issue Owner: @thesahindia

[MelvinBot]

Proposal

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

On DEV, opening any expense report or thread shows one of: infinite loading in the header, a loaded-but-incorrect report name, or a missing parent-navigation subtitle (From "…").

What is the root cause of that problem?

All three symptoms collapse to a single source of truth: the persisted reportAttributes Onyx derived value. The header title, the loading skeleton, and the From "…" subtitle all read the per-report reportName from it, so if that derived value doesn't hold a correct name for a report (and its parent), you get exactly these three symptoms:

• Skeleton gate is purely isLoading = !report?.reportID || !title — HeaderView.tsx:282. Empty derived name → infinite loading.
• getReportName falls back to the raw, often-stale report.reportName when the derived name is missing — ReportNameUtils.ts:1131. Stale derived value → incorrect name.
• The From "…" subtitle uses the parent report's derived name and is hidden entirely when it's empty (ParentNavigationSubtitle.tsx:152-154).

Why DEV-only: reportAttributes is persisted to disk — it is not in the RAM-only list (setup/index.ts:63). On launch it restores the on-disk value and recomputes incrementally: it seeds from the old value and only rebuilds reports that appear in the change deltas — reportAttributes.ts:306 and :560. A developer running an unreleased build (9.4.41-4) and switching branches accumulates a stale or wrong-schema persisted derived value; untouched reports keep their stale/empty names forever and are never rebuilt. Staging/production users on fresh data rarely hit this.

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

Invalidate the persisted reportAttributes derived value and force a full recompute when it can't be trusted — e.g. add a schema/version stamp to the derived value and discard-then-fully-recompute on mismatch (rather than restoring and only updating incrementally). This makes a schema change or corrupted on-disk value self-heal on the next launch instead of silently persisting stale names.

Diagnostic to confirm before implementing (medium confidence)

This needs a DEV runtime confirmation to pin the exact trigger. Ask the reporter to check the DEV console for:

• Log.info breadcrumbs from the derived engine — "restored from disk" vs a fresh compute, and any [OnyxDerived] compute for … threw (a swallowed throw in the compute would leave names stale for all reports — OnyxDerived/index.ts).
• Whether clearing the local Onyx DB / storage fixes it (would confirm the stale-persisted-value theory).
• Whether OpenReport actually resolves against the local backend (isolates the skeleton symptom, which is separately driven by isLoadingInitialReportActions).

A candidate secondary trigger is a __DEV__-only throw along the render/compute path (e.g. RenderHTML inside a <Text>, RenderHTML.tsx:47) getting swallowed by the derived compute's try/catch — which would also leave names unset on DEV only. The console error text would distinguish this from the stale-value path.

Key files

• src/libs/actions/OnyxDerived/configs/reportAttributes.ts — the derived compute (incremental gate + seed-from-old-value)
• src/setup/index.ts:63 — reportAttributes is persisted, not RAM-only
• src/libs/ReportNameUtils.ts:1131 — name resolution + stale fallback
• src/pages/inbox/HeaderView.tsx:282 — loading skeleton gate
• src/components/ParentNavigationSubtitle.tsx:152-154 — From "…" subtitle hidden when name empty

---

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

[ahmdshrif]

Proposal

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

On DEV, opening an expense report or thread intermittently shows infinite loading, the wrong report name, or a missing parent-navigation subtitle ("From …").

What is the root cause of that problem?

The name shown for a report comes from the report_attributes derived Onyx value, read via getReportName(report, derivedReportName), which falls back to report.reportName ?? '' when the derived name is absent:

App/src/libs/ReportNameUtils.ts

Lines 1114 to 1119 in 3e8642c

	function getReportName(report?: Report, derivedReportName?: string): string {
	if (!report?.reportID) {
	return '';
	}
	return derivedReportName ?? report.reportName ?? '';
	}

That derived value recomputes incrementally — only reports whose keys land in sourceValues/updates get re-derived; others keep their prior value:

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

Lines 302 to 360 in 3e8642c

	// if we already computed the report attributes and there is no new reports data, return the current value
	if ((useIncrementalUpdates && !sourceValues) || !reports) {
	return currentValue ?? {reports: {}, locale: null};
	}
	const reportUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT] ?? {};
	const reportMetadataUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_METADATA] ?? {};
	const reportActionsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_ACTIONS] ?? {};
	const reportNameValuePairsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS] ?? {};
	const transactionsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.TRANSACTION];
	const transactionViolationsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS];
	const policyTagsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.POLICY_TAGS];
	let dataToIterate = Object.keys(reports);
	// check if there are any report-related updates
	const reportUpdatesRelatedToReportActions = new Set<string>();
	for (const actions of Object.values(reportActionsUpdates)) {
	if (!actions) {
	continue;
	}
	for (const reportAction of Object.values(actions)) {
	if (reportAction?.childReportID) {
	reportUpdatesRelatedToReportActions.add(`${ONYXKEYS.COLLECTION.REPORT}${reportAction.childReportID}`);
	}
	}
	}
	// When only some accounts changed their name, refresh just the reports that use those accounts
	// Skipped when we're already refreshing everything (first load or a
	// locale change); in that case useIncrementalUpdates is false and the full scan below handles it.
	const personalDetailsChangedReportKeys: string[] = [];
	if (displayNameChanges instanceof Set && useIncrementalUpdates) {
	for (const reportKey of Object.keys(reports)) {
	const report = reports[reportKey];
	if (report && reportReferencesAccountIDs(report, displayNameChanges)) {
	personalDetailsChangedReportKeys.push(reportKey);
	}
	}
	}
	const updates = [
	...Object.keys(reportUpdates),
	...Object.keys(reportMetadataUpdates),
	...Object.keys(reportActionsUpdates),
	...Object.keys(reportNameValuePairsUpdates),
	...Array.from(reportUpdatesRelatedToReportActions),
	...policyChangedReportKeys,
	...personalDetailsChangedReportKeys,
	];
	if (useIncrementalUpdates) {
	// if there are report-related updates, iterate over the updates
	if (updates.length > 0 || !!transactionsUpdates || !!transactionViolationsUpdates || !!policyTagsUpdates) {
	dataToIterate = [];
	if (updates.length > 0) {

This gate was just reworked (derived-values optimization #96320 + onyx-store reland #96523) right before this DEV-only report. When a freshly-opened report's name depends on data that arrives without pushing that report's own key into updates (e.g. personal details / parent report resolving after the report), its derivedReportName is never computed. getReportName then returns ''/stale, and getParentNavigationSubtitle (reading the same state) yields no "From …" subtitle.

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

Guarantee the visible report is always re-derived. In reportAttributes.ts, when useIncrementalUpdates is on, push the current report's key into dataToIterate if its report_attributes entry is still missing (else fall back to a full scan):

if (currentReportID && !currentValue?.reports?.[currentReportID]) {
    updates.push(`${ONYXKEYS.COLLECTION.REPORT}${currentReportID}`);
}

Regression: this only adds the on-screen report on cache-miss, so it never skips an already-derived report and adds at most one entry.

[mukhrr]

Proposal

What is the root cause of that problem?

I found a cold-start race in OnyxDerived.init(). It restores a persisted derived value, then initializes each dependency subscription. Updates received before the final dependency connects are deliberately discarded:

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

Lines 40 to 80 in 3e8642c

	OnyxUtils.get(key).then((storedDerivedValue) => {
	let derivedValue = storedDerivedValue;
	if (derivedValue) {
	Log.info(`Derived value for ${key} restored from disk`);
	}
	const setDependencyValue = <Index extends number>(i: Index, value: Parameters<typeof compute>[0][Index]) => {
	dependencyValues[i] = value;
	};
	const checkAndMarkConnectionInitialized = (index: number) => {
	if (connectionInitializedFlags.at(index)) {
	return;
	}
	connectionInitializedFlags[index] = true;
	connectionsEstablishedCount++;
	if (connectionsEstablishedCount === totalConnections) {
	areAllConnectionsSet = true;
	Log.info(`[OnyxDerived] All connections initialized for key: ${key}`);
	}
	};
	// Create context once outside the function, swap values inline to avoid overhead of creating new objects frequently
	const context: DerivedValueContext<typeof key, typeof dependencies> = {
	currentValue: undefined,
	sourceValues: undefined,
	};
	const recomputeDerivedValue = (sourceKey?: string, sourceValue?: unknown, triggeredByIndex?: number) => {
	// If this recompute was triggered by a connection callback, check if it initializes the connection
	if (!areAllConnectionsSet && triggeredByIndex !== undefined) {
	checkAndMarkConnectionInitialized(triggeredByIndex);
	}
	// Before all connections are established, don't write to Onyx.
	// This prevents overwriting a valid disk-cached value with empty defaults,
	// and avoids N-1 unnecessary Onyx writes during initialization.
	// We still update dependencyValues via setDependencyValue so data accumulates correctly.
	if (!areAllConnectionsSet) {
	Log.info(`[OnyxDerived] not all connections set for ${key}, deferring Onyx write`);
	return;

When the final connection initializes, the code treats that callback as an ordinary incremental update by keeping the persisted derivedValue in context.currentValue and passing only the final dependency's sourceValue:

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

Lines 68 to 99 in 3e8642c

	const recomputeDerivedValue = (sourceKey?: string, sourceValue?: unknown, triggeredByIndex?: number) => {
	// If this recompute was triggered by a connection callback, check if it initializes the connection
	if (!areAllConnectionsSet && triggeredByIndex !== undefined) {
	checkAndMarkConnectionInitialized(triggeredByIndex);
	}
	// Before all connections are established, don't write to Onyx.
	// This prevents overwriting a valid disk-cached value with empty defaults,
	// and avoids N-1 unnecessary Onyx writes during initialization.
	// We still update dependencyValues via setDependencyValue so data accumulates correctly.
	if (!areAllConnectionsSet) {
	Log.info(`[OnyxDerived] not all connections set for ${key}, deferring Onyx write`);
	return;
	}
	context.currentValue = derivedValue;
	context.sourceValues = sourceKey && sourceValue !== undefined ? {[sourceKey]: sourceValue} : undefined;
	const spanId = `${CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE}_${key}`;
	startSpan(spanId, {
	name: CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE,
	op: CONST.TELEMETRY.SPAN_ONYX_DERIVED_COMPUTE,
	parentSpan: getSpan(CONST.TELEMETRY.SPAN_APP_STARTUP),
	attributes: {derivedKey: key},
	});
	try {
	// @ts-expect-error TypeScript can't confirm the shape of dependencyValues matches the compute function's parameters
	const newDerivedValue = compute(dependencyValues, context);
	Log.info(`[OnyxDerived] updating value for ${key} in Onyx`);
	derivedValue = newDerivedValue;
	setDerivedValue(key, derivedValue);

Therefore, changes accumulated from the earlier dependency callbacks are never reconciled with the persisted value. For example, reportAttributes sees an existing currentValue and no relevant report update from the final callback, so it returns the stale value instead of scanning the now fully loaded reports:

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

Lines 299 to 316 in 3e8642c

	// Use incremental updates when currentValue is already populated and no full recompute is required.
	// If currentValue has no reports (fresh install or cleared storage), fall back to a full scan.
	const useIncrementalUpdates = !!currentValue?.reports && Object.keys(currentValue.reports).length > 0 && !needsFullRecompute;
	// if we already computed the report attributes and there is no new reports data, return the current value
	if ((useIncrementalUpdates && !sourceValues) || !reports) {
	return currentValue ?? {reports: {}, locale: null};
	}
	const reportUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT] ?? {};
	const reportMetadataUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_METADATA] ?? {};
	const reportActionsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_ACTIONS] ?? {};
	const reportNameValuePairsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.REPORT_NAME_VALUE_PAIRS] ?? {};
	const transactionsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.TRANSACTION];
	const transactionViolationsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS];
	const policyTagsUpdates = sourceValues?.[ONYXKEYS.COLLECTION.POLICY_TAGS];
	let dataToIterate = Object.keys(reports);

This explains the inconsistent symptoms: the report header gets both its title and parent-navigation name from REPORT_ATTRIBUTES, so a missing/stale derived entry produces an incorrect title or missing “From …” subtitle:

App/src/pages/inbox/HeaderView.tsx

Lines 164 to 185 in 3e8642c

	// This is used to check if the report is a chat thread and has a parent invoice report.
	const isParentInvoiceAndIsChatThread = isChatThread && !!parentReport && isInvoiceReport(parentReport);
	const reportHeaderData = (!isTaskReport && !isChatThread && report?.parentReportID) || isParentInvoiceAndIsChatThread ? parentReport : report;
	const isParentOneTransactionThread = isOneTransactionThread(parentReport, grandParentReport, grandParentReportAction);
	const parentNavigationReport = isParentOneTransactionThread ? parentReport : reportHeaderData;
	const derivedParentReportName = useDerivedReportNameByReportID(parentNavigationReport?.parentReportID);
	const isReportHeaderDataArchived = useReportIsArchived(reportHeaderData?.reportID);
	const reportHeaderDataPolicy = usePolicy(reportHeaderData?.policyID);
	const {accountID: currentUserAccountID} = useCurrentUserPersonalDetails();
	// Use sorted display names for the title for group chats on native small screen widths
	const title = deprecatedGetReportName(reportHeaderData, reportAttributes);
	const subtitle = getChatRoomSubtitle(reportHeaderData, reportHeaderDataPolicy, conciergeReportID, translate, false, isReportHeaderDataArchived);
	// This is used to get the status badge for invoice report subtitle.
	const statusTextForInvoiceReport = isParentInvoiceAndIsChatThread
	? getReportStatusTranslation({stateNum: reportHeaderData?.stateNum, statusNum: reportHeaderData?.statusNum, translate})
	: undefined;
	const statusColorForInvoiceReport = isParentInvoiceAndIsChatThread ? getReportStatusColorStyle(theme, reportHeaderData?.stateNum, reportHeaderData?.statusNum) : {};
	const statusTooltipForInvoiceReport = isParentInvoiceAndIsChatThread
	? getReportStatusTooltipTranslation({stateNum: reportHeaderData?.stateNum, statusNum: reportHeaderData?.statusNum, translate})
	: undefined;
	const isParentReportHeaderDataArchived = useReportIsArchived(reportHeaderData?.parentReportID);
	const parentNavigationSubtitleData = getParentNavigationSubtitle(parentNavigationReport, policy, conciergeReportID, translate, derivedParentReportName, isParentReportHeaderDataArchived);

The existing tests initialize derived values against cleared storage and only add reports afterward, so they do not cover restarting with a stale persisted derived value while dependency subscriptions initialize:

App/tests/unit/OnyxDerivedTest.tsx

Lines 22 to 83 in 3e8642c

	const onyxDerivedTestSetup = () => {
	Onyx.init({keys: ONYXKEYS});
	initOnyxDerivedValues();
	};
	describe('OnyxDerived', () => {
	beforeAll(async () => {
	onyxDerivedTestSetup();
	});
	beforeEach(async () => {
	await Onyx.clear();
	});
	describe('reportAttributes', () => {
	beforeAll(async () => {
	await IntlStore.load(CONST.LOCALES.EN);
	await waitForBatchedUpdates();
	});
	beforeEach(async () => {
	await Onyx.set(ONYXKEYS.RAM_ONLY_ARE_TRANSLATIONS_LOADING, false);
	await waitForBatchedUpdates();
	});
	const mockReport: Report = {
	reportID: `test_1`,
	reportName: 'Test Report',
	type: 'chat',
	chatType: CONST.REPORT.CHAT_TYPE.POLICY_ROOM,
	lastVisibleActionCreated: '2023-01-01T00:00:00.000Z',
	lastMessageText: 'Test message',
	lastActorAccountID: 1,
	lastMessageHtml: '<p>Test message</p>',
	policyID: '123',
	ownerAccountID: 1,
	stateNum: CONST.REPORT.STATE_NUM.OPEN,
	statusNum: CONST.REPORT.STATUS_NUM.OPEN,
	};
	it('returns empty reports when dependencies are not set', async () => {
	await waitForBatchedUpdates();
	const derivedReportAttributes = await OnyxUtils.get(ONYXKEYS.DERIVED.REPORT_ATTRIBUTES);
	expect(derivedReportAttributes).toMatchObject({
	reports: {},
	});
	});
	it('computes report attributes when reports are set', async () => {
	await Onyx.set(`${ONYXKEYS.COLLECTION.REPORT}${mockReport.reportID}`, mockReport);
	await waitForBatchedUpdates();
	const derivedReportAttributes = await OnyxUtils.get(ONYXKEYS.DERIVED.REPORT_ATTRIBUTES);
	expect(derivedReportAttributes).toMatchObject({
	reports: {
	[mockReport.reportID]: {
	reportName: mockReport.reportName,
	},
	},
	});
	});

git log -S shows that the deferred-write behavior was introduced by commit 8213456b43d8a5dfd8e1f9b4013f717574de4692 to avoid overwriting cached values during cold start, but it did not add a full reconciliation when the last dependency becomes ready.

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

I think we should update recomputeDerivedValue() in src/libs/actions/OnyxDerived/index.ts to detect the transition from “not all connections initialized” to “all initialized” and perform that first computation without the restored currentValue. This forces every derived configuration to reconcile once from the complete dependency snapshots; later callbacks retain the existing incremental path.

A small illustrative change would be:

+ const isInitializingLastConnection = !areAllConnectionsSet;
  checkAndMarkConnectionInitialized(triggeredByIndex);

- context.currentValue = derivedValue;
+ context.currentValue = isInitializingLastConnection && areAllConnectionsSet ? undefined : derivedValue;

I would add a regression test that pre-populates a stale REPORT_ATTRIBUTES value and the report collections, initializes OnyxDerived, and verifies that the current expense/thread name replaces the stale cached value once every dependency connection is ready.

This does not regress the original cold-start protection: no derived value is written while dependencies are incomplete. It adds exactly one full computation at the transition to the ready state. Subsequent report, action, transaction, policy, and personal-detail changes continue using their current incremental sourceValue behavior.

What alternative solutions did you explore? (Optional)

I considered clearing REPORT_ATTRIBUTES or special-casing HeaderView, but that would only mask the header symptom and leave other persisted derived values stale. I also considered removing the pre-initialization guard, but that would restore the race it was added to prevent by allowing partially loaded dependency data to overwrite valid cached values.