[Due for payment 2026-05-20] [$250] TypeError: Cannot use 'in' operator to search for 'deleted' in <string> — crash on /home when opening a report from "Begin"

[mountiny]

Bug Report

Error

TypeError: Cannot use 'in' operator to search for 'deleted' in <expense-update notification string>
    at isDeletedAction (src/libs/ReportActionsUtils.ts:224)
    at Array.filter (anonymous)
    at getFirstVisibleReportActionID (src/libs/ReportActionsUtils.ts:1663)
    at useMemo (...)
    at ReportActionsList (...)

Sentry

This is the same fingerprint as the previously closed APP-6E0. It is still receiving fresh events on recent releases — please reopen the Sentry group / verify it has not been auto-resolved by inactivity.

Action performed

1. Open the Home page (/home).
2. From the "For you" section, click the Begin button on a "Submit X report" task that opens an expense report whose history contains a legacy "expense has been updated with official data from an imported card" report action (common on accounts with imported card transactions).
3. The report opens in the RHP and the report list crashes with the TypeError above.

Expected result

The report list renders and the existing "expense updated with official data from an imported card" notification action is treated as not-deleted (its real shape).

Actual result

isDeletedAction throws TypeError: Cannot use 'in' operator to search for 'deleted' in <string>, which propagates up through getFirstVisibleReportActionID → useMemo in ReportActionsList and crashes the report view.

Platforms

• All web/mWeb (Sentry events come from web). Native is not directly observed but the same code path runs there.

Reproducible in staging? / production?

• Production: Yes (live Sentry events).
• Staging: Likely yes when there is at least one legacy "expense updated by imported card" notification action in the report history.

---

Root Cause Analysis

The crash happens inside isDeletedAction in src/libs/ReportActionsUtils.ts, specifically the last clause on line 224:

return isLegacyDeletedComment
    || !!message.at(0)?.deleted
    || (!!originalMessage && 'deleted' in originalMessage && !!originalMessage?.deleted);

originalMessage is obtained from getOriginalMessage(reportAction):

function getOriginalMessage<T extends ReportActionName>(reportAction: OnyxInputOrEntry<ReportAction<T>>): OriginalMessage<T> | undefined {
    if (!Array.isArray(reportAction?.message)) {
        return reportAction?.message ?? reportAction?.originalMessage;
    }
    return reportAction?.originalMessage;
}

For some legacy/OldDot expense-update report actions, the backend stores the user-facing notification as a plain string (e.g. "The <date> <merchant> expense has been updated with official data from an imported card") — either directly in originalMessage, or in message when message is not an array, in which case getOriginalMessage falls through to it.

The !!originalMessage truthiness check passes for any non-empty string, so execution reaches 'deleted' in originalMessage. The JS in operator requires its right operand to be an object; with a string it throws the TypeError shown above.

The TypeScript signature of getOriginalMessage is OriginalMessage<T> | undefined, so callers see an object-shaped type and the runtime mismatch is invisible at compile time. The team is already aware this happens at runtime — there is an explicit Log.info('Original message is not an object for reportAction: ', ...) in getWhisperedTo of the same file, and several sibling helpers (getWhisperedTo, isResolvedActionableWhisper, hasReasoning) already wrap their '<key>' in originalMessage usage with a typeof originalMessage === 'object' guard. isDeletedAction is the outlier.

Why this triggers on Home → "Begin": clicking "Begin" navigates to the report and mounts ReportActionsList, which builds a useMemo that calls getFirstVisibleReportActionID(sortedReportActions). That helper does sortedReportActions.filter(action => !isDeletedAction(action) || …). A single legacy expense-update action anywhere in the report's history is enough to throw and crash the entire list.

This is the same defect previously triaged as #83937, which was closed without a fix; the targeted PR #83940 was closed without merging.

---

Proposed Fix (robust, centralized)

A site-by-site typeof guard (the approach in PR #83940) only covers the call sites we currently see. There are ~15+ '<key>' in originalMessage usages in the codebase (see git grep "in originalMessage"), so the same bug class can resurface elsewhere any time a new caller is added.

The robust fix has two layers:

1. Centralize the guard in getOriginalMessage (defense-in-depth)

Make getOriginalMessage honor its existing TypeScript contract by returning undefined for non-object values. This protects every caller at once, including future ones, and matches the declared return type OriginalMessage<T> | undefined.

In src/libs/ReportActionsUtils.ts:

function getOriginalMessage<T extends ReportActionName>(reportAction: OnyxInputOrEntry<ReportAction<T>>): OriginalMessage<T> | undefined {
    const candidate = !Array.isArray(reportAction?.message)
        ? reportAction?.message ?? reportAction?.originalMessage
        : reportAction?.originalMessage;

    // Some legacy/OldDot report actions store a plain notification string in `message`/`originalMessage`.
    // The TS type promises an object-shaped `OriginalMessage`, and downstream code uses the `in` operator
    // (which throws on non-objects). Normalize non-object values to undefined to honor the contract.
    if (candidate === null || typeof candidate !== 'object') {
        return undefined;
    }
    return candidate as OriginalMessage<T>;
}

2. Keep an explicit guard at the isDeletedAction callsite (belt-and-suspenders)

Even with (1), defensively narrow on the in operator at the immediate crash site so that any future regression in getOriginalMessage (or any caller bypassing it) cannot reintroduce this exact crash:

return isLegacyDeletedComment
    || !!message.at(0)?.deleted
    || (!!originalMessage && typeof originalMessage === 'object' && 'deleted' in originalMessage && !!originalMessage?.deleted);

3. Apply the same guard to other unguarded in originalMessage call sites

While we're touching this, sweep the remaining unguarded '<key>' in originalMessage usages so the same crash class cannot surface in other components. Today these include (non-exhaustive):

• src/libs/ReportActionsUtils.ts — lines 541, 558, 993–995, 1156, 1161
• src/libs/ReportSecondaryActionUtils.ts — line 413
• src/pages/Debug/Report/DebugReportActions.tsx — line 68
• src/pages/inbox/report/VacationDelegateText.tsx — line 24
• src/pages/inbox/report/ContextMenu/PopoverReportActionContextMenu.tsx — line 347
• src/components/ReportActionItem/TripRoomPreview.tsx — line 143
• src/components/ReportActionItem/TaskPreview.tsx — line 91
• src/libs/actions/Transaction.ts — line 716

Once (1) is in place these are no longer crash-prone in practice (they all go through getOriginalMessage), but adding the typeof === 'object' prefix keeps the codebase self-consistent with the existing guarded sites and makes static analysis happier.

---

Unit test coverage

Add the following cases to tests/unit/ReportActionsUtilsTest.ts. The first three are regression tests for this bug; the last is a positive case for the centralized normalization in getOriginalMessage.

isDeletedAction — must not crash when originalMessage is a string

Inside the existing describe('isDeletedAction', ...) block (around line 1625):

it('should return false (not crash) when originalMessage is a plain string', () => {
    const reportAction = {
        created: '2023-09-27 10:00:00.000',
        reportActionID: '123456789',
        actionName: CONST.REPORT.ACTIONS.TYPE.ADD_COMMENT,
        // Legacy/OldDot shape: notification stored as string instead of object
        originalMessage: 'The September 27, 2023 Chick-fil-A expense has been updated with official data from an imported card',
        message: [
            {
                html: 'The September 27, 2023 Chick-fil-A expense has been updated with official data from an imported card',
                type: 'COMMENT',
                text: 'The September 27, 2023 Chick-fil-A expense has been updated with official data from an imported card',
            },
        ],
    } as unknown as ReportAction;

    // Regression: prior to the fix this throws TypeError: Cannot use 'in' operator to search for 'deleted' in <string>
    expect(() => ReportActionsUtils.isDeletedAction(reportAction)).not.toThrow();
    expect(ReportActionsUtils.isDeletedAction(reportAction)).toBe(false);
});

it('should return false (not crash) when message is a non-array string and originalMessage is missing', () => {
    const reportAction = {
        created: '2023-09-27 10:00:00.000',
        reportActionID: '123456789',
        actionName: CONST.REPORT.ACTIONS.TYPE.ADD_COMMENT,
        // getOriginalMessage falls through to message when message is not an array;
        // ensure a string `message` cannot crash isDeletedAction either.
        message: 'The September 27, 2023 Chick-fil-A expense has been updated with official data from an imported card',
    } as unknown as ReportAction;

    expect(() => ReportActionsUtils.isDeletedAction(reportAction)).not.toThrow();
    expect(ReportActionsUtils.isDeletedAction(reportAction)).toBe(false);
});

getFirstVisibleReportActionID — must not crash when the action list contains a legacy string-message action

Add a new describe:

describe('getFirstVisibleReportActionID', () => {
    it('does not crash on a sortedReportActions list that contains a legacy string-originalMessage action', () => {
        const created = {
            created: '2023-09-27 09:00:00.000',
            reportActionID: '1',
            actionName: CONST.REPORT.ACTIONS.TYPE.CREATED,
        } as unknown as ReportAction;

        const legacyExpenseUpdate = {
            created: '2023-09-27 10:00:00.000',
            reportActionID: '2',
            actionName: CONST.REPORT.ACTIONS.TYPE.ADD_COMMENT,
            originalMessage: 'The September 27, 2023 Chick-fil-A expense has been updated with official data from an imported card',
            message: [{html: 'updated', type: 'COMMENT', text: 'updated'}],
        } as unknown as ReportAction;

        const visibleAction = {
            created: '2023-09-27 11:00:00.000',
            reportActionID: '3',
            actionName: CONST.REPORT.ACTIONS.TYPE.ADD_COMMENT,
            originalMessage: {html: 'Hello', whisperedTo: []},
            message: [{html: 'Hello', type: 'COMMENT', text: 'Hello'}],
        } as unknown as ReportAction;

        const sorted = [created, legacyExpenseUpdate, visibleAction];

        // Regression: prior to the fix this throws inside Array.prototype.filter -> isDeletedAction.
        expect(() => ReportActionsUtils.getFirstVisibleReportActionID(sorted)).not.toThrow();
        expect(ReportActionsUtils.getFirstVisibleReportActionID(sorted)).toBe('2');
    });
});

getOriginalMessage — normalizes non-object values to undefined

If a unit test file for getOriginalMessage doesn't already exist, add a describe('getOriginalMessage', ...) block in the same test file. (Note: getOriginalMessage is currently not exported. To keep the targeted fix testable directly, either export it from ReportActionsUtils.ts or test the behavior indirectly through a calling helper.)

describe('getOriginalMessage', () => {
    it('returns undefined when message/originalMessage is a string (legacy shape)', () => {
        const reportAction = {
            actionName: CONST.REPORT.ACTIONS.TYPE.ADD_COMMENT,
            reportActionID: '1',
            originalMessage: 'plain string from legacy backend',
        } as unknown as ReportAction;

        // @ts-expect-error -- export getOriginalMessage from ReportActionsUtils for this test, or assert via a dependent helper.
        expect(ReportActionsUtils.getOriginalMessage(reportAction)).toBeUndefined();
    });

    it('returns the object when originalMessage is object-shaped', () => {
        const reportAction = {
            actionName: CONST.REPORT.ACTIONS.TYPE.ADD_COMMENT,
            reportActionID: '1',
            originalMessage: {html: 'hi', whisperedTo: []},
        } as unknown as ReportAction;

        // @ts-expect-error -- see note above.
        expect(ReportActionsUtils.getOriginalMessage(reportAction)).toEqual({html: 'hi', whisperedTo: []});
    });
});

These three test groups cover both the centralized normalization and the immediate caller, and they fail today on main against the unguarded code, so they will lock in the regression.

---

Workaround

None at the user level — the report view is unrenderable for affected reports until the fix lands.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022053829595538569183
• Upwork Job ID: 2053829595538569183
• Last Price Increase: 2026-05-11

Issue Owner

Current Issue Owner: @eVoloshchak

[MelvinBot]

Proposal

What is the root cause of that problem?

isDeletedAction uses the in operator on originalMessage with only a truthiness guard (!!originalMessage). For legacy/OldDot report actions, getOriginalMessage can return a plain string at runtime (when message is a string rather than an array, the function returns it directly). A non-empty string passes the truthiness check, but the in operator throws TypeError because it requires an object operand.

The team is already aware of this runtime mismatch — getWhisperedTo has both a typeof originalMessage === 'object' guard and an explicit Log.info for the non-object case. isDeletedAction is missing that same guard.

This was previously reported as #83937; the fix PR #83940 was closed without merging.

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

Two layers:

1. Centralize the guard in getOriginalMessage — return undefined when the resolved value is not an object. This honors the declared return type (OriginalMessage<T> | undefined) and protects all callers (current and future) at once.

2. Add a typeof originalMessage === 'object' guard at the isDeletedAction crash site (belt-and-suspenders), matching the existing pattern used in getWhisperedTo, isResolvedActionableWhisper, hasReasoning, etc.

Investigation details

Crash call chain: ReportActionsList → useMemo → getFirstVisibleReportActionID → isDeletedAction → 'deleted' in originalMessage → TypeError

Unguarded in originalMessage usages (all vulnerable to the same crash class):

• ReportActionsUtils.ts:224 — isDeletedAction (the crash site)
• ReportActionsUtils.ts:541, 558, 993-995
• DebugReportActions.tsx:68, TripRoomPreview.tsx:143, TaskPreview.tsx:91, PopoverReportActionContextMenu.tsx:347, VacationDelegateText.tsx:24, ReportSecondaryActionUtils.ts:413, Transaction.ts:716

Already-guarded usages (correct pattern): getWhisperedTo (L602/610), isResolvedActionableWhisper (L1153), isResolvedConciergeCategoryOptions (L1174), isResolvedConciergeDescriptionOptions (L1183), hasReasoning (L4567).

Centralizing the guard in getOriginalMessage eliminates the entire bug class. The site-specific guards are belt-and-suspenders for consistency with existing code.

---

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.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

isDeletedAction is fed an originalMessage that, at runtime, is a plain string instead of an object. The crash is on this line:

https://github.com/Expensify/App/blob/main/src/libs/ReportActionsUtils.ts#L224

return isLegacyDeletedComment || !!message.at(0)?.deleted || (!!originalMessage && 'deleted' in originalMessage && !!originalMessage?.deleted);

The !!originalMessage truthiness check passes for non-empty strings, then 'deleted' in originalMessage throws TypeError: Cannot use 'in' operator to search for 'deleted' in <string> because in only accepts objects.

The string comes from getOriginalMessage:

https://github.com/Expensify/App/blob/main/src/libs/ReportActionsUtils.ts#L440-L445

function getOriginalMessage<T extends ReportActionName>(reportAction: OnyxInputOrEntry<ReportAction<T>>): OriginalMessage<T> | undefined {
    if (!Array.isArray(reportAction?.message)) {
        return reportAction?.message ?? reportAction?.originalMessage;
    }
    return reportAction?.originalMessage;
}

For legacy backend report actions (in this case the "expense updated with official data from an imported card" notification surfaced from the Begin task on /home), reportAction.message is a serialized string, not an object. The !Array.isArray branch happily returns that string, even though the declared return type is OriginalMessage<T> | undefined — i.e., an object. So the type contract is violated and every caller that uses the in operator is at risk.

I counted ~15 unguarded '<key>' in originalMessage usages (src/libs/ReportActionsUtils.ts lines 224, 541, 558, 993, 994, 995, 1156, 1161; src/libs/ReportSecondaryActionUtils.ts:413; src/libs/actions/Transaction.ts:716; src/components/ReportActionItem/TaskPreview.tsx:91; src/components/ReportActionItem/TripRoomPreview.tsx:143; src/pages/inbox/report/ContextMenu/PopoverReportActionContextMenu.tsx:347; src/pages/inbox/report/VacationDelegateText.tsx:24; src/pages/Debug/Report/DebugReportActions.tsx:68). Any of these can throw the same TypeError for the same kind of legacy payload — isDeletedAction is just the one that happens to fire when the report list renders.

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

I'd fix it in one place: make getOriginalMessage honor its declared return type by normalizing anything that isn't a real object to undefined. That single change makes every originalMessage && '<key>' in originalMessage site safe automatically.

 function getOriginalMessage<T extends ReportActionName>(reportAction: OnyxInputOrEntry<ReportAction<T>>): OriginalMessage<T> | undefined {
-    if (!Array.isArray(reportAction?.message)) {
-        return reportAction?.message ?? reportAction?.originalMessage;
-    }
-    return reportAction?.originalMessage;
+    const candidate = !Array.isArray(reportAction?.message) ? (reportAction?.message ?? reportAction?.originalMessage) : reportAction?.originalMessage;
+
+    // Legacy report actions can store `message` as a plain string. The declared return type is an object,
+    // and downstream callers use `'<key>' in originalMessage`, which throws on non-objects. Normalize here.
+    return candidate && typeof candidate === 'object' ? (candidate as OriginalMessage<T>) : undefined;
 }

For belt-and-braces at the actual crash site, I'd also tighten the guard in isDeletedAction:

-    return isLegacyDeletedComment || !!message.at(0)?.deleted || (!!originalMessage && 'deleted' in originalMessage && !!originalMessage?.deleted);
+    return isLegacyDeletedComment || !!message.at(0)?.deleted || (!!originalMessage && typeof originalMessage === 'object' && 'deleted' in originalMessage && !!originalMessage?.deleted);

The remaining ~13 unguarded '<key>' in originalMessage call sites don't need individual diffs because the getOriginalMessage change already protects them — the originalMessage && ... prefix that precedes most of them now correctly short-circuits on undefined. The few that destructure straight into '<key>' in originalMessage without a leading truthiness check (e.g., ReportActionsUtils.ts:541, 558, 1156, 1161) sit inside functions that have already established originalMessage is set, so they continue to work as long as getOriginalMessage no longer hands back a string.

Tests. I'd add unit coverage in tests/unit/ReportActionsUtilsTest.ts:

• getOriginalMessage returns undefined for a report action whose message is a plain string.
• isDeletedAction returns false (not throws) for that same shape.
• getFirstVisibleReportActionID (or the report-list filter that iterates isDeletedAction) processes a list containing a legacy string-message action without crashing.

What alternative solutions did you explore? (Optional)

• Guarding every single in-on-originalMessage call site individually. It's ~15 spots, easy to miss one, and any future caller would inherit the same footgun. Fixing the source — getOriginalMessage — is one line of real change and removes the class of bug.
• Migrating the offending legacy backend actions to the new object-shaped format on read/normalization layer. That's the right long-term fix, but it's a larger backend coordination and doesn't help the millions of already-persisted records in user Onyx storage. The client still needs to defend itself.
• Returning {} instead of undefined from getOriginalMessage. Tempting because it keeps callers that do originalMessage?.foo happy, but it would silently make 'foo' in originalMessage return false for genuine object messages that just don't have foo set — fine — versus making distinguishing "missing" from "not-an-object" impossible. undefined aligns with the declared return type and preserves caller intent.

[melvin-bot]

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

[wildan-m]

Proposal

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

Opening an expense report from the Home page (/home → "For you" → Begin on a "Submit X report" task) crashes the report view with TypeError: Cannot use 'in' operator to search for 'deleted' in <string>. The error is thrown from isDeletedAction while ReportActionsList is computing getFirstVisibleReportActionID, so the entire report list fails to render whenever the report's history contains at least one legacy "expense has been updated with official data from an imported card" notification action.

What is the root cause of that problem?

isDeletedAction in src/libs/ReportActionsUtils.ts reads originalMessage via the local getOriginalMessage helper and then evaluates 'deleted' in originalMessage without first verifying that originalMessage is an object:

App/src/libs/ReportActionsUtils.ts

Lines 196 to 224 in 35320c9

	function isDeletedAction(reportAction: OnyxInputOrEntry<ReportAction | OptimisticIOUReportAction>): boolean {
	if (isInviteOrRemovedAction(reportAction) || isActionableMentionWhisper(reportAction) || isActionableCardFraudAlert(reportAction)) {
	return false;
	}
	if (reportAction?.actionName === CONST.REPORT.ACTIONS.TYPE.HOLD || reportAction?.actionName === CONST.REPORT.ACTIONS.TYPE.UNHOLD) {
	return false;
	}
	// for report actions with this type we get an empty array as message by design
	if (
	reportAction?.actionName === CONST.REPORT.ACTIONS.TYPE.REIMBURSEMENT_DIRECTOR_INFORMATION_REQUIRED ||
	reportAction?.actionName === CONST.REPORT.ACTIONS.TYPE.CREATED_REPORT_FOR_UNAPPROVED_TRANSACTIONS ||
	reportAction?.actionName === CONST.REPORT.ACTIONS.TYPE.REASSIGN_APPROVER
	) {
	return false;
	}
	const message = reportAction?.message ?? [];
	if (!Array.isArray(message)) {
	return message?.html === '' || !!message?.deleted;
	}
	const originalMessage = getOriginalMessage(reportAction);
	// A legacy deleted comment has either an empty array or an object with html field with empty string as value
	const isLegacyDeletedComment = message.length === 0 || message.at(0)?.html === '';
	return isLegacyDeletedComment || !!message.at(0)?.deleted || (!!originalMessage && 'deleted' in originalMessage && !!originalMessage?.deleted);

The in operator throws TypeError if its right operand is not an object, and getOriginalMessage can return a plain string. That happens because the helper falls through to reportAction?.message whenever message is not an array — and for some legacy/OldDot expense-update notifications the backend stores the user-facing text directly as a string in message/originalMessage:

App/src/libs/ReportActionsUtils.ts

Lines 440 to 446 in 35320c9

	function getOriginalMessage<T extends ReportActionName>(reportAction: OnyxInputOrEntry<ReportAction<T>>): OriginalMessage<T> | undefined {
	if (!Array.isArray(reportAction?.message)) {
	return reportAction?.message ?? reportAction?.originalMessage;
	}
	return reportAction?.originalMessage;
	}

So when ReportActionsList runs sortedReportActions.filter(action => !isDeletedAction(action) ...) and that array contains one legacy expense-update action, the truthy-string originalMessage reaches the 'deleted' in originalMessage check and throws, propagating up through getFirstVisibleReportActionID → the useMemo in ReportActionsList and unmounting the report:

App/src/libs/ReportActionsUtils.ts

Lines 1660 to 1665 in 35320c9

	if (!Array.isArray(sortedReportActions)) {
	return '';
	}
	const sortedFilterReportActions = sortedReportActions.filter((action) => !isDeletedAction(action) || (action?.childVisibleActionCount ?? 0) > 0 || isOffline);
	return sortedFilterReportActions.length > 1 ? sortedFilterReportActions.at(sortedFilterReportActions.length - 2)?.reportActionID : undefined;
	}

The sibling helper getWhisperedTo in the same file already guards its 'whisperedTo' in originalMessage check with typeof originalMessage === 'object', and hasReasoning does the same. isDeletedAction is simply missing the equivalent guard:

App/src/libs/ReportActionsUtils.ts

Lines 599 to 612 in 35320c9

	const originalMessage = getOriginalMessage(reportAction);
	const message = getReportActionMessage(reportAction);
	if (!(originalMessage && typeof originalMessage === 'object' && 'whisperedTo' in originalMessage) && !(message && typeof message === 'object' && 'whisperedTo' in message)) {
	return [];
	}
	if (message !== null && !Array.isArray(message) && typeof message === 'object' && 'whisperedTo' in message) {
	return message?.whisperedTo ?? [];
	}
	if (originalMessage && typeof originalMessage === 'object' && 'whisperedTo' in originalMessage) {
	return originalMessage?.whisperedTo ?? [];
	}

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

In src/libs/ReportActionsUtils.ts, narrow the final clause of isDeletedAction so the 'deleted' in originalMessage operand is reached only when originalMessage is actually an object. Concretely, the existing combined condition !!originalMessage && 'deleted' in originalMessage && !!originalMessage?.deleted becomes !!originalMessage && typeof originalMessage === 'object' && 'deleted' in originalMessage && !!originalMessage?.deleted. That is the exact pattern already used at the two other in originalMessage callsites in the same file (getWhisperedTo and hasReasoning), so the codebase remains internally consistent and a non-object originalMessage is treated, correctly, as "not a deleted action".

This guard is intentionally local to isDeletedAction rather than changing the shared getOriginalMessage helper. getOriginalMessage is used by ~30 callers across the codebase, several of which intentionally consume the string fallback through reportAction?.message (e.g. text-only fields read via ?.html / template helpers). Normalizing non-object returns to undefined inside getOriginalMessage would silently change behavior for those callers and risk regressing unrelated flows; pushing the guard down to the one operator that actually requires an object operand is the smaller, safer correction and is also what already-merged sites in this file do.

To lock the regression in, add a Jest case to the existing describe('isDeletedAction', ...) block in tests/unit/ReportActionsUtilsTest.ts that constructs a report action whose originalMessage is a plain string ("...expense has been updated with official data from an imported card..."), asserts that calling isDeletedAction does not throw, and asserts it returns false. The test fails on main today (throws TypeError) and passes after the one-line guard is added, which is what the bug reporter's Sentry trace requires.

The user-visible crash surface is the same one observed in Sentry group APP-6E0, so once this guard is merged, the reported Home → "Begin" report-open crash and any other call path that funnels a legacy expense-update notification action through isDeletedAction (LHN previews via shouldReportActionBeVisible, getLastVisibleAction, getReportPreviewMessage, etc.) stop crashing as well — those all reach the same throwing line through the same helper.

What alternative solutions did you explore? (Optional)

Centralizing the normalization inside getOriginalMessage (returning undefined whenever the resolved value is not an object) was considered and rejected. The helper's TypeScript signature already promises OriginalMessage<T> | undefined, so on paper it's the "correct" place to enforce the invariant — but doing so would change the runtime contract for every existing caller in a single commit. A non-trivial number of those callers reach getOriginalMessage precisely through the !Array.isArray(message) branch and depend on the string fallback in downstream ?.html / message-template code paths. Even with TypeScript on our side, the change is too broad for a targeted Sentry regression fix and would warrant its own design discussion plus a sweep of all consumers. Keeping the fix at the one throwing operator preserves existing behavior everywhere else and avoids piggy-backing a wider refactor onto a crash fix.

A type-only fix (tightening getOriginalMessage's return type or sprinkling typeof guards across the ~15 sibling '<key>' in originalMessage sites in the codebase) was also considered. Those other sites are not currently throwing in Sentry, and several of them already include their own typeof === 'object' guards. A blanket sweep would be a worthwhile follow-up cleanup but is out of scope for this regression; the immediate crash group APP-6E0 is closed by guarding the one throwing line.

Implementation

main...wildan-m:App:wildan/90198-guard-isdeletedaction-typeof

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[yusufdeveloper2903]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @KJ21-ENG Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[github-actions]

⚠️ @Abdulloh0109 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.