[$250] UNREPORTEDTRANSACTION report action doesn't show and no "Explain" sparkle link

[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.53-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #86565
Email or phone of affected tester (no customers): poipio514+owner4@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome, Samsung Galaxy A52 / Android 14, iPhone 13 / iOS 18.7.1
App Component: Chat Report View

Action Performed:

Preconditions:

• logged in with a user that at least has one workspace and invited a member to the workspace
• set the member as approver of admin's expense in advanced workflow
• enable "Rules" in more feature

Steps:

1. (Admin) Create and submit an expense that violates a receipt-required policy (can submit over $75 expense)
2. (Approver) Reject the admin's expense
3. (Admin) open the expense details that just rejected by approver

Expected Result:

the UNREPORTEDTRANSACTION report action is shown and there's an inline "Explain" sparkle link

Actual Result:

UNREPORTEDTRANSACTION report action doesn't show and no "Explain" sparkle link

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: @paulnjs

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022041472896542506133
• Upwork Job ID: 2041472896542506133
• Last Price Increase: 2026-04-07

[MelvinBot]

Proposal

What is the root cause of that problem?

The visibility check for UNREPORTED_TRANSACTION report actions in src/libs/ReportActionsUtils.ts:1148-1153 requires the fromReport (the expense report the transaction was moved from) to exist in Onyx:

if (actionName === CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION) {
    const {fromReportID} = unreportedTransactionOriginalMessage;
    const fromReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${fromReportID}`];
    return !!fromReport;  // <-- always false when fromReport was deleted
}

When an approver rejects a single-expense report via rejectMoneyRequest (src/libs/actions/IOU/index.ts:9574-9590), the expense report is deleted from Onyx (SET to null) and the transaction's reportID is set to UNREPORTED_REPORT_ID ('0'). The backend then creates an UNREPORTED_TRANSACTION action with fromReportID pointing to the now-deleted report. The visibility check looks up that report in Onyx, gets undefined, and hides the action — along with the "Explain" sparkle link.

The same issue also affects deleteAppReport, which creates UNREPORTED_TRANSACTION actions and then deletes the source report.

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

Change the visibility check for UNREPORTED_TRANSACTION in shouldReportActionBeVisible (src/libs/ReportActionsUtils.ts:1148-1153) to not require the fromReport to exist. The action should be visible as long as fromReportID is present and is not UNREPORTED_REPORT_ID ('0'), matching the pattern used by MOVED_TRANSACTION at lines 1155-1167.

Replace the current check with:

if (actionName === CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION) {
    const {fromReportID} = unreportedTransactionOriginalMessage;
    return !!fromReportID && fromReportID !== CONST.REPORT.UNREPORTED_REPORT_ID;
}

This ensures the action is shown when a transaction was un-reported from a real expense report (even if that report no longer exists), but hidden when fromReportID is the sentinel '0' value.

What alternative solutions did you explore? (Optional)

• Always returning true: Simpler but would show actions with fromReportID = '0' (personal space origin), which doesn't make sense to display.
• Keeping the report in Onyx after rejection: Would require changes across multiple rejection flows and doesn't address the fundamental design issue — a deleted report shouldn't prevent showing a valid report action.

---

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

[melvin-bot]

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

[wildan-m]

Proposal

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

After an approver rejects a single-expense report, the UNREPORTED_TRANSACTION report action is not shown in the transaction thread, and the "Explain" sparkle link is missing.

What is the root cause of that problem?

The visibility check for UNREPORTED_TRANSACTION actions in shouldReportActionBeVisible requires the source report (fromReport) to exist in Onyx:

App/src/libs/ReportActionsUtils.ts

Lines 1148 to 1153 in 114fa06

	if (actionName === CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION) {
	const unreportedTransactionOriginalMessage = getOriginalMessage(reportAction as OnyxEntry<ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION>>) ?? {};
	const {fromReportID} = unreportedTransactionOriginalMessage as OriginalMessageUnreportedTransaction;
	const fromReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${fromReportID}`];
	return !!fromReport;
	}

When a single-expense report is rejected via rejectMoneyRequest, the expense report is optimistically deleted from Onyx (SET to null) and the transaction's reportID is set to UNREPORTED_REPORT_ID ('0'):

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

Lines 9574 to 9590 in 114fa06

	} else {
	// For reports with single expense: Delete the report
	optimisticData.push(
	{
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: null,
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	reportID: CONST.REPORT.UNREPORTED_REPORT_ID,
	...(transactionCommentCleanup ?? {}),
	},
	},
	);

The backend then creates an UNREPORTED_TRANSACTION action whose fromReportID points to the now-deleted report. The visibility check looks it up in Onyx, gets undefined, and returns false — hiding the action along with the "Explain" sparkle link.

The same issue also affects deleteAppReport, which creates UNREPORTED_TRANSACTION actions optimistically and then deletes the source report on success:

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

Lines 5892 to 5899 in 114fa06

	// 4. Add UNREPORTED_TRANSACTION report action
	const unreportedAction = buildOptimisticUnreportedTransactionAction(childReportID, reportID);
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${childReportID}`,
	value: {[unreportedAction.reportActionID]: unreportedAction},
	});

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

Lines 5947 to 5951 in 114fa06

	successData.push({
	onyxMethod: Onyx.METHOD.SET,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: null,
	});

In this flow, the action is briefly visible during the optimistic phase (report has pendingFields.preview: DELETE but still exists), but disappears once the server confirms and the report is SET to null.

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

Change the visibility check for UNREPORTED_TRANSACTION in shouldReportActionBeVisible to not require the fromReport to exist in Onyx. The action should be visible as long as fromReportID is present and is not UNREPORTED_REPORT_ID ('0'), matching the logic used by the MOVED_TRANSACTION check at lines 1155-1167 for the sentinel value:

App/src/libs/ReportActionsUtils.ts

Lines 1155 to 1167 in 114fa06

	if (isMovedTransactionAction(reportAction)) {
	const movedTransactionOriginalMessage = getOriginalMessage(reportAction);
	const toReportID = movedTransactionOriginalMessage?.toReportID;
	const fromReportID = movedTransactionOriginalMessage?.fromReportID;
	if (fromReportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
	return false;
	}
	const toReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${toReportID}`];
	const fromReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${fromReportID}`];
	return !!fromReport || !!toReport;
	}

Replace lines 1148-1153 with a check that validates the fromReportID value itself rather than looking up the report object. This ensures the action is shown when a transaction was unreported from a real expense report (even if that report no longer exists in Onyx), while still hiding it when fromReportID is the sentinel '0' value (personal space origin).

What alternative solutions did you explore? (Optional)

1. Preserving the report in Onyx after deletion — instead of SET to null, keep a minimal stub with a deleted: true flag so the visibility check still finds it. This would require changes across rejectMoneyRequest, deleteAppReport, and potentially other deletion flows. It also contradicts the existing pattern where deleted reports are fully removed from Onyx. Much higher complexity for the same outcome.
2. Always returning true for UNREPORTED_TRANSACTION — simpler but would incorrectly show actions where fromReportID is '0' (personal space origin), which doesn't make sense to display.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/87239-unreported-transaction-visibility?expand=1

[neerajbachani]

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

After an approver rejects a single-expense report, the UNREPORTED_TRANSACTION report action is not shown in the transaction thread, and the "Explain" sparkle link is missing.

---

What is the root cause of that problem?

In prepareRejectMoneyRequestData (src/libs/actions/IOU/index.ts), when an approver rejects a single expense on a non-delayed-submission workspace report, two issues occur:

1. buildOptimisticUnreportedTransactionAction is never called — so the UNREPORTED_TRANSACTION report action is never added to the transaction thread.
   Compare this with deleteAppReport (src/libs/actions/Report/index.ts), which correctly creates this action.

2. The expense report is optimistically deleted using SET: null immediately.
   As a result, even if the action existed, the visibility check in shouldReportActionBeVisible (src/libs/ReportActionsUtils.ts) returns !!fromReport → false, hiding it.

Additionally, UnreportedTransactionAction.tsx does not support the "Explain" sparkle link because:

• OriginalMessageUnreportedTransaction has no reasoning field
• The component does not use ReportActionItemMessageWithExplain (unlike MovedTransactionAction.tsx)

---

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

1. src/libs/actions/IOU/index.ts — Main fix

In prepareRejectMoneyRequestData, single-expense non-delayed branch:

- // Optimistic: delete report immediately
- {
-     onyxMethod: Onyx.METHOD.SET,
-     key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
-     value: null,
- },

+ // Optimistic: soft-delete (matching deleteAppReport pattern)
+ // so fromReport still exists during optimistic phase
+ {
+     onyxMethod: Onyx.METHOD.MERGE,
+     key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
+     value: {pendingFields: {preview: CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE}},
+ },

Move the actual deletion to successData:

+ // Success: fully remove the report
+ {
+     onyxMethod: Onyx.METHOD.SET,
+     key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
+     value: null,
+ },

Add the missing action (mirroring deleteAppReport):

+ const unreportedAction = buildOptimisticUnreportedTransactionAction(
+     childReportID,
+     reportID,
+ );

+ optimisticData.push({
+     onyxMethod: Onyx.METHOD.MERGE,
+     key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${childReportID}`,
+     value: {[unreportedAction.reportActionID]: unreportedAction},
+ });

+ successData.push({
+     onyxMethod: Onyx.METHOD.MERGE,
+     key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${childReportID}`,
+     value: {[unreportedAction.reportActionID]: {pendingAction: null}},
+ });

+ failureData.push({
+     onyxMethod: Onyx.METHOD.MERGE,
+     key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${childReportID}`,
+     value: {[unreportedAction.reportActionID]: {pendingAction: null}},
+ });

---

2. src/libs/ReportActionsUtils.ts — Visibility fix

if (actionName === CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION) {
    const {fromReportID} = unreportedTransactionOriginalMessage;

-   const fromReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${fromReportID}`];
-   return !!fromReport;

+   // Show even if the source report was deleted from Onyx
+   return !!fromReportID && fromReportID !== CONST.REPORT.UNREPORTED_REPORT_ID;
}

---

3. src/types/onyx/OriginalMessage.ts — Add reasoning field

type OriginalMessageUnreportedTransaction = {
    fromReportID: string;

+   /** Reasoning for the automated move (used by Explain feature) */
+   reasoning?: string;
};

---

4. src/components/ReportActionItem/UnreportedTransactionAction.tsx — Add Explain sparkle

+ import {hasReasoning} from '@libs/ReportActionsUtils';
+ import ReportActionItemMessageWithExplain from './ReportActionItemMessageWithExplain';

type UnreportedTransactionActionProps = {
    action: OnyxEntry<ReportAction>;

+   childReport: OnyxEntry<Report>;
+   originalReport: OnyxEntry<Report>;
};

- function UnreportedTransactionAction({action}: UnreportedTransactionActionProps) {
+ function UnreportedTransactionAction({action, childReport, originalReport}: UnreportedTransactionActionProps) {

+   if (hasReasoning(action)) {
+       return (
+           <ReportActionItemMessageWithExplain
+               action={action}
+               report={childReport}
+               originalReport={originalReport}
+           />
+       );
+   }

    // existing render...
}

---

5. src/pages/inbox/report/PureReportActionItem.tsx — Pass new props

case CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION:
    return (
        <UnreportedTransactionAction
            action={action}
+           childReport={report}
+           originalReport={parentReport}
        />
    );

---

What alternative solutions did you explore? (Optional)

Instead of changing the optimistic deletion to a soft-delete (pendingFields.preview = DELETE), we could modify only the visibility check to always return true when a fromReportID is present.

However, the soft-delete approach is preferred because it:

• Keeps behavior consistent with deleteAppReport
• Allows UnreportedTransactionAction to render the strikethrough state during the optimistic phase
• Matches existing UX patterns

MelvinBot and wildan-m’s proposals only address the visibility fix (#2) but miss the primary root cause: the action is never created (#1), and the "Explain" feature is not wired (#3–#5).

[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).

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

The root cause is that UNREPORTED_TRANSACTION is treated like a live reference to a report, instead of a historical event.

Right now the action is only shown if the source report still exists in Onyx:

App/src/libs/ReportActionsUtils.ts

Lines 1147 to 1152 in 9960a33

	if (actionName === CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION) {
	const unreportedTransactionOriginalMessage = getOriginalMessage(reportAction as OnyxEntry<ReportAction<typeof CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION>>) ?? {};
	const {fromReportID} = unreportedTransactionOriginalMessage as OriginalMessageUnreportedTransaction;
	const fromReport = reports?.[`${ONYXKEYS.COLLECTION.REPORT}${fromReportID}`];
	return !!fromReport;

But when a single-expense report is rejected, that source report is deleted from Onyx. After that, the action still exists, but its visibility check fails, so the row disappears along with the "Explain" link.

There is a second sign of the same problem: the message for UNREPORTED_TRANSACTION also rebuilds itself from the current report data in Onyx instead of from the action payload:

App/src/libs/ReportUtils.ts

Lines 6968 to 6991 in 9960a33

	function getUnreportedTransactionMessage(
	translate: LocalizedTranslate,
	action: ReportAction,
	// TODO: Make this required when https://github.com/Expensify/App/issues/66411 is done
	conciergeReportID?: string,
	) {
	const movedTransactionOriginalMessage = getOriginalMessage(action) ?? {};
	const {fromReportID} = movedTransactionOriginalMessage as OriginalMessageMovedTransaction;
	const fromReport = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${fromReportID}`];
	// This will be fixed as follow up https://github.com/Expensify/App/pull/75357
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	const reportName = Parser.htmlToText(getReportName({report: fromReport, conciergeReportID}) ?? fromReport?.reportName ?? '');
	let reportUrl = getReportURLForCurrentContext(fromReportID);
	if (fromReportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
	reportUrl = `${environmentURL}/r/${findSelfDMReportID()}`;
	return translate('iou.unreportedTransaction', reportUrl);
	}
	return translate('iou.movedTransactionFrom', reportUrl, reportName);
	}

At creation time, we already know the source report name and URL context, but we only save fromReportID in the action payload:

App/src/libs/ReportUtils.ts

Lines 7443 to 7466 in 9960a33

	type: typeof CONST.REPORT.ACTIONS.TYPE.MOVED_TRANSACTION | typeof CONST.REPORT.ACTIONS.TYPE.UNREPORTED_TRANSACTION,
	transactionThreadReportID: string | undefined,
	originalReportID: string,
	): ReportAction {
	const selfDMReportID = findSelfDMReportID();
	const isFromPersonalSpace = originalReportID === CONST.REPORT.UNREPORTED_REPORT_ID || originalReportID === selfDMReportID;
	const fromReportID = isFromPersonalSpace ? CONST.REPORT.UNREPORTED_REPORT_ID : originalReportID;
	const reportName = allReports?.[`${ONYXKEYS.COLLECTION.REPORT}${isFromPersonalSpace ? selfDMReportID : originalReportID}`]?.reportName ?? '';
	const url = isFromPersonalSpace ? getReportURLForCurrentContext(findSelfDMReportID()) : getReportURLForCurrentContext(originalReportID);
	const [actionText, messageHtml] = [`moved this expense from ${reportName}`, `moved this expense from <a href='${url}' target='_blank' rel='noreferrer noopener'>${reportName}</a>`];
	return {
	actionName: type,
	reportID: transactionThreadReportID,
	actorAccountID: deprecatedCurrentUserAccountID,
	avatar: getCurrentUserAvatar(),
	created: DateUtils.getDBTime(),
	originalMessage: {fromReportID},
	message: [
	{
	type: CONST.REPORT.MESSAGE.TYPE.TEXT,
	html: messageHtml,
	text: actionText,
	},

So the real issue is not only the visibility check. The action model itself does not store enough data to survive report deletion.

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

Make UNREPORTED_TRANSACTION a self-contained historical action.

Instead of depending on the source report still being present in Onyx, the action payload should include the display data needed to render it after deletion, for example:

• fromReportID
• fromReportName
• optionally a small flag that tells us whether the source was personal space

Then:

• Render the message from the action payload first, and only fall back to live Onyx report data for older actions.
• Show the action based on whether the payload represents a real past move, not on whether the old report record still exists.
• Keep the current "Explain" behavior unchanged, since it depends on reasoning, not on the report object.

This is stronger because it fixes the underlying design problem: report actions are immutable history, so they should not disappear just because related records were later deleted.

As a follow-up, it may also make sense to apply the same pattern to MOVED_TRANSACTION, since it already has similar deleted-report edge cases.

What alternative solutions did you explore? (Optional)

1. Change only the visibility check for UNREPORTED_TRANSACTION.
   This is the smallest fix, but it only solves the missing row. The message can still lose the source report name after deletion, so it does not fully fix the root cause.

2. Keep deleted reports in Onyx as tombstones.
   This would make the current check pass, but it adds storage complexity and keeps the wrong dependency in place. A historical action should not need a deleted report record to remain valid.

3. Always show the action when fromReportID exists.
   Better than the current logic, but still incomplete for the same reason: the action is still not self-contained.